A proposal for CMT tag unification

Nomenclature

We can split architecture related CMT tags into two categories

• Host tags these are tags that CMT will find by itself, these tags should always appear no matter if one executes CMT inside a project environment or not. Examples are: Darwin, Linux, gcc345, slc45, ...
• Target tags These are tags we want to compile our software for. The most important one is the string set to the CMTCONFIG environment variable. From this string we usually derive other tags, such as slc4-ia32, gcc34, optimized, ...

Our current situation

We are using at the moment two different sets of tags, i.e. the “LCG/AA and LHCb” tags and the “Atlas” tags which have the same meaning, e.g.

      slc4_ia32_gcc34 is equal to i686-slc4-gcc34-opt

In LCGCMT/LCG_Settings where all tag information is stored we are currently using in several cases the same tag name for a “host tag” and for a “target tag”. E.g. we are deriving gcc34 both from slc4_ia32_gcc34 and from gcc345.

Goals

The goals of this propsal are to

1. unify the tag names, i.e. to use only one set of tags
2. clear up the inconsistencies with derived tags used in the host and target context.

A proposal for change

Goal 1 - unification of tag names

Concerning the unification of tag names, we propose to use the "Atlas" convention of tag names, e.g. for an upcoming slc5 tag the string would be x86_64-slc5-gcc41-opt . The reason for this is, that we could more easily automatically compute tag names, e.g. get the architecture type via "uname -p", also if we move to a 64 bit architecture on Darwin the currently used string "amd64" does even make less sense than before.

So the rules for creating a tag name are

• A concatenation by hyphens of the constituents [architecture]-[operating system]-[compiler name and version]-[optimization level]
• All strings are lower case
• [architecture] is usually the result of a "uname -p" on a linux/darwin os or the tag name returned by cmt
• [operating system] is the tag name returned by CMT reduced to the "non-patch level" e.g. slc5, osx105
• [compiler name and version] is the tag name returned by CMT reduced to the "non-patch level" e.g. two digits for a gcc compiler version.
• [optimization level] are the strings "opt", "dbg" or "cov" (for code coverage testing tag names).

Goal 2 - Clear distinction between host and target tags

Before reading on please note that a "compatibility layer" for this step will be provided

The proposal in this context is to remove all the current "derived" tag names, i.e. all tag names which are either derived from a CMT internal host tag or from a CMTCONFIG derived target tag, because of the overlap of tag names in some cases. Further we propose to prepend all host tags with the string "host-" and all target tags with the string "target-".

examples for host tags

     tag slc45    host-slc4
     tag gcc421   host-gcc41
     tag Linux    host-Linux

examples for target tags

     tag i686-slc5-gcc41-opt    target-i686    target-slc5  target-gcc34  target-opt
     tag x86_64-slc5-gcc43-dbg  target-x86_64  target-slc5  target-gcc43  target-dbg

This way we can achieve a clear distinction between the host and target context and will benefit from several advantages, see next paragraph.

Advantages of this proposal

If this proposal was implemented it would improve the current situation in several ways

1. The unification of tag names will simplify the software distribution because we will not need to create any compatibility layers between the two different tag names with the same meaning anymore (e.g. LCG/AA nightly builds, LCG/AA external software packages, Gaudi releases, etc. )
2. As we will have a clear distinction between the host and target context, the cross compilation of software will be easier, e.g. compiling 32 bit on a 64 bit host will be achieved by the line macro_append cppflags "" host-x86_64&target-i686 " -m32 "
3. An interface to a compiler in LCGCMT will be easier to achieve, e.g. compiling gcc 3.4 on a slc5 node will be achieved by the line macro CXX "" host-slc5&target-gcc34 " gcc-3.4"
4. Also cross compilation from other linux distributions can be made easier, deriving for a newly invented tag name its capabilities
5. One could even go a step further and allow cross compilations across operating systems, e.g. compile windows on linux hosts via wine, etc.

Compatibility layer

The new tag names will be applied only from slc5 names onwards, i.e. the currently used tag names in LCG/AA and LHCb for slc4, osx105, etc. will stay as is.

Concerning the distinction between host and target tags, as the "old" derived tags will be removed from LCG_Settings, we will need some compatibility layer for some time, until everybody has moved successfully to the new derived tag names. The proposal in this context is to create a new LCGCMT package "LCG_SettingsCompat" which will contain all the "old" style derived tag names and project librarians can "cmt use" in their own projects in order to provide backwards compatibility. Once confident that the new tag names are applied successfully the "using" of this package can be removed and it will be removed again from the cvs repository.

Time scale for an implementation

The new scheme can be implemented in LCGCMT and tested in the LCG/AA nightlies "dev" slot (HEAD of everything), it can go into production from the next major configuration series on, i.e. LCG 56.

-- StefanRoiser - 03 Oct 2008