Mark Olesen 9e3d06853e ENH: add 'subcommand' handling to wmake (#1693 )

- initial split of wmake-related commands into "plumbing" and
  "porcelain" akin to how git handles things.

- wmakeBuildInfo (very low-level), now relocated to the wmake/scripts
  and accessible for the user as "wmake -build-info".

  This satisfies a long-standing desire to access build information
  in a fashion similar to the api/patch information.

CONFIG: avoid git information when building with a debian/ directory

- when a 'debian/' directory exists, there is a high probability that
  the '.git/' directory is from debian and not from OpenFOAM (ie,
  useless here). This corresponds to an implicit '-no-git', which has
  no effect when building from pristine sources.

ENH: wmakeCheckPwd becomes scripts/wmake-check-dir

- accessible for the user as "wmake -check-dir" and with 1 or 2
  directory names. A wmakeCheckPwd symlink left for compatibility.

2020-05-12 10:05:24 +02:00

2.5 KiB

Raw Blame History

META-INFO

Meta-information is generally for OpenFOAM internal use only.

The format, content and meaning may be changed at anytime without notice. If any of these are changed, these are some of places that will need to be updated accordingly:

bin/foamEtcFile
bin/tools/foamConfigurePaths
bin/tools/foamPackRelease
etc/openfoam
wmake/scripts/wmake-build-info

api-info

This file and its contents are to be tracked by git.

File content (api) generated by wmake -build-info from the OPENFOAM define in wmake/rules/General/general
File content (patch) is manually generated content.

build-info

This file is never to be tracked by git, but may be present in shipped source archives.

File content (branch, build) generated by wmake -build-info from git information and cached from previous wmake (api)

Content types

api

Format: date +%y%m

4-digit year-month (YYMM) integer corresponding to the major release or in unusual cases an intermediate release. Example, 1712 for the Dec-2017 release.

patch

Format: date +%y%m%d

6-digit year-month-day (YYMMDD) integer corresponding to a patch-level for the given released API.
The first release can have a patch value of 0 or 1 which indicates that it is unpatched or just released. Alternatively it can have a patch value corresponding to the release date.

The patch value is only meaningful together with the api value. However, for development branches, the patch level should not be ascribed too much meaning, but will often correspond to the last merge with a maintenance (eg, master) branch.

Flow of information

Changes in the build information must be reflected in information available in the final binaries. Conversely, it is necessary for later distributions to have a record of the same information.

property	source	saved
api	wmake/rules	api-info
patch	manual (api-info)	build-info
branch	git	build-info
build	git	build-info

The command wmake -build-info -check is used to determine if the saved information needs synchronization. The command wmake -build-info -update performs the synchronization.

Notes

The saved information is split into two separate files. The api-info contains more permanent information, whereas the build-info is more transient in nature.

2020-05-05

2.5 KiB Raw Blame History