[CMake] CMake 2.8.0 RC 1 ready for testing!

[Martin Apel]

Hi Brad,

Brad King wrote:
> Hi Martin,
>
> Thanks for trying the release candidate.  It is helpful to get feedback
> early in the release process.
>
> Martin Apel wrote:
>   
>> However I found a few quirks in the first rc:
>> 1. I have quite a lot of Fortran files in one of our projects. We use
>> the Intel Fortran 11 compiler to compile these.
>>     When gathering the objects into a static library CMake 2.6 used to
>> call "ar" and "ranlib".
>>     Now it seems to call the Intel tool xiar
>>     
>
> I believe CMake 2.6 used xiar for C and C++ static libraries, and this
> fix was to make Fortran consistent with those.
>
>   
>> which in turn calls xild and this step takes ages (about one minute).
>>     
>
> Wow.  Perhaps it is looking for inter-procedural optimizations.
>
> You can tell CMake not to use xiar by pretending that it is not available.
> CMake uses find_program to locate the tool and stores the result in the
> cache entry "XIAR".  For a single build tree you can do
>
>   cmake . -DXIAR=
>
> to erase the search result.  If you want to stop it all the time, add
> a line to tell CMake never to search for XIAR in the first place.
> It must be done before the Fortran language is enabled because afterwards
> the result of the search will already have been used.  Try this:
>
>   cmake_minimum_required(VERSION 2.6)
>   set(XIAR "") # Never use Intel's xiar
>   project(FOO Fortran)
>
> While this solution will work around the trouble for your project,
> perhaps we should consider this a general bug since it was done for
> C and C++ in CMake 2.6 already.  According to the Intel user guide
> we only really need to use xiar when the object files were compiled
> with "-ipo" to enable inter-procedural optimization (is this correct?).
> If you want to look at changing CMake's default behavior please open
> a bug report for further discussion.
>   
Thanks a lot. I opened up a bug report with the number 9615 for this
issue. I think CMake should
only use xiar in case the ipo option is present. We will use the ipo
option in the near future, so
simply setting XIAR="" would not work.
>   
>> 2. Fortran-related as well: On Linux we used to link in the following
>> Intel Fortran libraries explicitly: ifcoremt, imf, irc.
>>     With CMake 2.8 the following additional and unneeded (for us)
>> libraries can be found on the command line for the linker:
>>     ifport, ifcore, svml, ipgo, intlc, irc_s. As we do not copy these
>> shared libraries to our runtime directory, the resulting
>>     executables do not run. This means, that 2.8 is not
>> downward-compatible with 2.6 in this respect, so I would have to
>>     code a version check into the CMakeLists.txt. Is this intended
>> behaviour?
>>     
>
> CMake 2.8 automatically detects the implicit runtime libraries used
> by the compiler to create a binary for each language.  When building
> a link line for a mixed-language binary one of the languages is chosen
> to invoke the linker, so it is known that its libraries will be implicit.
> Implicit libraries for other languages are added explicitly.
>
> Most of the time this all does nothing.  A single-language binary will
> always use its own linker so no extra libraries are needed.  A mixed
> C/C++ binary always uses the C++ linker and the C implicit libs are a
> subset so nothing happens.
>
> This should only be happening if the executable contains both C++
> and Fortran code.  While developing mixed-language C++/Fortran support
> we considered the support in CMake 2.6 so immature that it was not
> worth trying to be compatible.  Our rationale is that it just plain
> didn't work out of the box...every project would have to link to
> implicit libraries explicitly for each platform anyway.
>
>   
>> Or can I tell CMake not to add any additional compiler libraries?
>>     
>
> It adds libraries listed in CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES
> that are not also listed in CMAKE_CXX_IMPLICIT_LINK_LIBRARIES.
> Just add this line:
>
>   set(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)
>
> It tells CMake to ignore any Fortran implicit libraries it detected.
> Another approach is to erase unwanted libraries:
>
>   list(REMOVE_ITEM CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES
>      ifport ifcore svml ipgo intlc irc_s)
>
> and stop explicitly linking known implicit libraries yourself.  An
> advantage of this approach is that things will work out of the box
> by default for some user building your code.  The extra work to
> remove libraries is for your prebuilt distribution.
>   
I tried this and it worked without problems.

Keep up the good work!

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090929/8ac3be8c/attachment.htm>