CMTDownload

You can download the sources of the version v1r6 of CMT or prebuilt binaries for some plateforms :

The changes for this version

New features

1. Lock and unlock features

   
   The new cmt lock command acts upon the current package while cmt lock acts upon a specified package. A text file named lock.cmt is installed within the cmt|mgr directory, and the shell command described in the macro named lock_command is tried.

   Similarly the cmt unlock tries to execute the shell command described in the macro named unlock_command.

   You should try the command cmt show macro lock_command and cmt show macro unlock_command to see how they are defined by default (within the requirements file of CMT.

   All cmt commands that may modify a package (typically all cmt build commands) will not be executed if a conflicting lock is detected (ie a lock set by another user).

2. Default behaviour changed for the cmt create command

   
   The package creation (using the cmt create action) now occurs by default (ie when the last path argument is not specified) from the current directory instead of using the default installation root (ie where CMT itself is installed). Obviously the previous behaviour can be reproduced using either one of the two following forms:

    
   > cmt create Foo v1 ${CMTROOT}/../..
           

   or

    
   > cd ${CMTROOT}/../..
   > cmt create Foo v1
           

   Path specification (provided in the last argument of the cmt create command) may contain relative path (eg mydev, ../../, ../mydev) or absolute ones)

3. Add the cmt remove command

   
   The cmt remove command (with exactly the same syntax as the cmt create command) removes the specified version of the specified package, if it exists and if not conflicting lock is set onto it. If positive conditions are met, everything below (and included) the version directory will be deleted.

   In addition, when after deleting the version, the package directory becomes really empty it is also deleted.

4. New convention for constituent and source file specific customizing macros

   
   Constituent specific customizing macros and source file specific ones are now renamed so as to remove previous ambiguities with the package customizing macros. Eg for customizing the C++ compiler, we used to have _cppflags, _cppflags and _cppflags. Obvious conflicts were occuring when a constituent or a source file name had the same name as the package (inducing duplicated options or limitations to the customizing features). These macros have now be renamed to app__cppflags (for applications) lib__cppflags (for libraries) and __cppflags (while the _cppflags macro is left unchanged).

   However, old definitions are currently maintained in the appropriate make fragments so as to keep the backward compatibility, but may become obsolescent in future CMT releases).

5. New option for applications and libraries for sharing source files

   
   Applications and libraries may be assigned a suffix which will be added to binary files created by the various compilers for this constituent. This permits to re-use some source files for several constituents, so as to build different flavours of the same constituent with different compiler options, as in the following example:

    
   
   macro lib_Foo_cppflags " ... -O2 ..."
   library Foo -suffix=opt   *.cxx
   
   macro lib_FooDbg_cppflags " ... -g ..."
   library FooDbg -suffix=dbg *.cxx
   
           

6. New default search path for user defined make fragments

   
   User defined make fragments are now searched for from the directories cmt/fragments or mgr/fragments instead of the directory ../fragments. This should enforce the need (and the goal) to keep all CMT-related files within one unique directory tree.

   For backward compatibility reasons, the old search path (../fragments) is maintained for some time, but may become obsolescent in future releases.

7. New selection options for cmt broadcast

   
   It is possible to restrict the broadcast actions to packages found in a subset of the CMTPATH list, using the -local or -depth=.

   Then the -all_packages option permit to extend the broadcast to all possible packages.

    
   > cmt broadcast -local              (1)
   > cmt broadcast -depth=          (2)
   > cmt broadcast -all_packages       (3)
           

   1. The packages only found at the same level as the current package are considered
   2. The packages only found at the same level as the current package or among the first entries in the CMTPATH list are considered
   3. All the packages and versions currently available through the CMTPATH list are considered

8. New native support of Windows/nmake context

   
   A complete support of Windows/nmake is now offered. This includes:
   • Production of setup scripts for environment variable definitions (ie construction of a setup.bat script).
   • Automatic and transparent generation of makefiles with the nmake syntax, starting form a standard and transparent root makefile (named NMake, installed when cmt config is run).

     Therefore, the main make command will be :

      
     > nmake /f nmake
                 

     with same behaviour as for the Unix equivalent.

9. Selective import from used packages

   
   So far, all used packages did import their customizing macros (eg _linkopts, include paths or compiler options).

   A new option (-no_auto_imports) to be specified in the use statement permits to discard the automatic insertion of these macros into the use_xxx standard macros. This should be combined with the new -import=package option for constituent statements which permits a constituent to selectively import these macros for its specific usage.

   
   

10. Environment variables (set) and path variables (path_xxx) can now contain references to macros

    
    It is possible to include references to macros (ie. using the $(...) notation) within the definition of an environment variable or a path variable. These references will be internally expanded before their actual evaluation (typically when running the setup scripts). This naturally includes the possiblity to refer to standard macors such as tag or bin.

    As an example one could specify (using the two standard macros PACKAGE_ROOT and tag):

     
    path_append LD_LIBRARY_PATH "$(PACKAGE_ROOT)/$(tag)"
                

    It should be noticed that references towards other environment variables are still kept un-expanded (as it was the case before).

Internal changes or bug fixing

1. The Cmt class has been reorganized. Methods corresponding to cmt actions are now uniformly named do_.
2. A new class named PAwk derived from Awk permits to filter the output of a shell command.
3. The production of preprocessor options with ${ppcmd} has been fixed when used with fortran (it needed quotes).
4. Some bugs fixed in the cmt checkout operation.
5. In the script for cmt cvs actions (cmt_buildcvsinfos2.sh), the cvstags option did not handle correctly the cmt style (ie when the requirements file is stored in the cmt directory instead of the mgr one).
6. Added support for the branch tags in the cmt cvstags command (thus for the cmt checkout command as well)
7. The ../classes directory for java outputs is now transparently created when needed.
8. The usage of the system specific file separators (either '/' on Unix or '\' on Windows) has been largely cleaned up in various places of the CMT sources, systematically using CmtSystem::file_separator () (which provides the appropriate variant according to the current operating system).
9. The dependency generation ignored the include_path specification (thus losing many references to actually dependent header files)