Next: Main features of the
Up: Bundling source code, libraries
Previous: Structure of a pack
Contents
Index
A pack will be named by GmkPack according to the following convention :
$(PREFIX)$(RELEASE)_$(BRANCH).$(VERSION).$(STAMP).$(OPTIONS)$(SUFFIX)
where :
- $(PREFIX)
- is a conventional prefix (possibly empty) chosen at the installation time of GmkPack
- $(RELEASE)
- is the label of the code release (alphanumeric string)
- $(BRANCH)
- is the label of the modification (or branch) on top of the code release (alphanumeric string)
- $(VERSION)
- is the version number of the branch (numeric string between 00 and 99)
- $(STAMP)
- is a stamp for the configuration file used, recalling the compiler and the compiler version (as far as possible)
- $(OPTIONS)
- is the label of the compilation options used (character string)
- $(SUFFIX)
- is a conventional suffix (possibly empty) chosen at the installation time of GmkPack
Examples : cy31t1_main.01.L0209.x.pack
; 31t1_necbf.10.SX6V20.ftrace
However a working pack could be given a user-defined name (like an alias).
Discussion : the naming convention should be revisited for several reasons :
- the name is not accurate enough to specify the code version : for instance, to identify a branch on top of another one
it should rather be something like :
$(BRANCH).$(VERSION)@$(PREFIX)$(RELEASE)_$(REF_BRANCH).$(REF_VERSION).$(STAMP).$(OPTIONS)$(SUFFIX)
while only main packs would be named as before.
- the definition of the field $(STAMP) should be re-examined to enable the use of an alternative compiler version in a flexible way.
- a solution should be found to handle simultaneously different families of source code.
Next: Main features of the
Up: Bundling source code, libraries
Previous: Structure of a pack
Contents
Index
EL KHATIB Ryad
2008-05-23