[CMake] CMAKE_ROOT env variable not honored anymore

[Martin Apel]

Hi all,

we used CMake 2.8 so far and had used the environment variable 
CMAKE_ROOT to tell the cmake binary, where to find its Modules etc. 
directories.
We used this in a multiplatform context to store the 
architecture-independent files of CMake only once.
It seems, that CMake 3.0 does not honor this environment variable 
anymore. Is this a bug or a feature?


Martin
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Generating multiple targets in parallel generates common prerequisites twice

[Martin Apel]

Hi Eike,

thanks for the pointer. I verified, that it works with the current git 
version of cmake.

So the problem will be fixed with the next CMake release.

Martin

On 08/01/14 10:00, Rolf Eike Beer wrote:

Am 08.01.2014 09:42, schrieb Martin Apel:

Hi all,

I hope this question hasn't been asked before, I haven't found
anything useful in the archive.

Assume I have the following small CMakeLists.txt file:

CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
PROJECT(testCMakeDeps)

ADD_LIBRARY(foo SHARED foo.cpp)
ADD_LIBRARY(bar SHARED bar.cpp)

ADD_EXECUTABLE(test test.cpp)
TARGET_LINK_LIBRARIES(test foo bar)

ADD_EXECUTABLE(test2 test2.cpp)
TARGET_LINK_LIBRARIES(test2 foo bar)

This creates two executables, which both depend on the same two shared
libraries. When generating a Makefile for this on Linux,
one can start the compilation process via 'make -j2 test test2', i.e.
name two separate targets on the command line.
However CMake seems to generate a Makefile, which does not work
correctly in this case. The shared libraries are generated twice.
This seems to be a CMake issue, not a Make issue, I can write a
Makefile by hand, which works correctly in this case.
Is there any way around the duplicate generation (which sometimes
fails, because the same libraries may be generated simultaneously)?

Could you please try a CMake version from the next branch, I think that
this has been fixed recently.

Eike
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Generating multiple targets in parallel generates common prerequisites twice

[Martin Apel]

Hi all,

I hope this question hasn't been asked before, I haven't found anything 
useful in the archive.


Assume I have the following small CMakeLists.txt file:

CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
PROJECT(testCMakeDeps)

ADD_LIBRARY(foo SHARED foo.cpp)
ADD_LIBRARY(bar SHARED bar.cpp)

ADD_EXECUTABLE(test test.cpp)
TARGET_LINK_LIBRARIES(test foo bar)

ADD_EXECUTABLE(test2 test2.cpp)
TARGET_LINK_LIBRARIES(test2 foo bar)

This creates two executables, which both depend on the same two shared 
libraries. When generating a Makefile for this on Linux,
one can start the compilation process via 'make -j2 test test2', i.e. 
name two separate targets on the command line.
However CMake seems to generate a Makefile, which does not work 
correctly in this case. The shared libraries are generated twice.
This seems to be a CMake issue, not a Make issue, I can write a Makefile 
by hand, which works correctly in this case.
Is there any way around the duplicate generation (which sometimes fails, 
because the same libraries may be generated simultaneously)?


Martin
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] LLVM Dragonegg usage in CMakeLists.txt

[Martin Apel]

I am trying to use the LLVM dragonegg plugin for GCC in a project, which
is built using CMake. However I have a hard time figuring out how to
tell CMake, what it should do. Dragonegg is a plugin, which makes GCC
use part of the LLVM infrastructure to optimize the compiled code. In my
case,
I am trying to compile some Fortran files with GCC using this plugin,
postprocess the emitted LLVM code and link the result into a library.

Here is what I currently do:
   SET(LL_FILES)
   SEPARATE_ARGUMENTS(DRAGONEGG_OPTIONS UNIX_COMMAND
"${CMAKE_Fortran_FLAGS} -I ${CMAKE_CURRENT_SOURCE_DIR}/ins -S
-fplugin=dragonegg.so -fplugin-arg-dragonegg-emit-ir")
   FOREACH(File ${Src})
  GET_FILENAME_COMPONENT(Filename ${File} NAME_WE)
  SET (LL_FILES ${LL_FILES} ${CMAKE_CURRENT_BINARY_DIR}/${Filename}.ll)
  ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${Filename}.ll
 COMMAND ${CMAKE_Fortran_COMPILER}
${DRAGONEGG_OPTIONS} -o ${CMAKE_CURRENT_BINARY_DIR}/${Filename}.ll ${File}
 DEPENDS ${File})
   ENDFOREACH()
   ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/form.ll
  COMMAND llvm-link -S -o
${CMAKE_CURRENT_BINARY_DIR}/form.ll ${LL_FILES}
  DEPENDS ${LL_FILES})
   ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/form.opt.ll
  COMMAND opt -o
${CMAKE_CURRENT_BINARY_DIR}/form.opt.ll ${CMAKE_CURRENT_BINARY_DIR}/form.ll
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/form.ll)
   ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/form.opt.o
  COMMAND llc -o ${CMAKE_CURRENT_BINARY_DIR}/form.S
${CMAKE_CURRENT_BINARY_DIR}/form.opt.ll
  COMMAND as -o
${CMAKE_CURRENT_BINARY_DIR}/form.opt.o ${CMAKE_CURRENT_BINARY_DIR}/form.S
  DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/form.opt.ll)
   ADD_LIBRARY(form_ce STATIC ${CMAKE_CURRENT_BINARY_DIR}/form.opt.o)
   SET_TARGET_PROPERTIES(form_ce PROPERTIES LINKER_LANGUAGE Fortran)


Unfortunately calling the Fortran compiler this way looses the
dependency scanning, which is important for Fortran module access. I
tried using IMPLICIT_DEPENDS on the first custom command, but the
documentation says, that it only works for C and CXX. I also thought
about directly putting the dragonegg options into CMAKE_Fortran_FLAGS
and use ADD_LIBRARY, but this won't work as well, because the files
output by the dragonegg plugin are LLVM source files, which have to be
explicitly run through the code generator to turn them into normal
object files.
Any ideas how to solve this?

Martin
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Martin Apel]

On 29/03/11 19:56, David Cole wrote:
> Now that we have released CMake 2.8.4, *now* would be a great time to 
> prioritize bug fixes for the next release of CMake.

http://public.kitware.com/Bug/view.php?id=11942

This currently keeps us from upgrading to 2.8.3 or 2.8.4.

Thanks,

Martin
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build on one machine, test on multiple

[Martin Apel]

Hi all,

here is what I did now:
I created an installer image (BitRock installer in our case) containing
the normal deliverables of our software plus the following items:
- Some scripts needed to carry out our tests. This also contains
software needed to carry out the tests (Squish)
- A complete CMake installation
- The following CMake-generated files from the build directory:
  - CTestCustom.cmake
  - DartConfiguration.tcl
  - CTestTestfile.cmake
- Post-installation script

The last item is a script, which is run by the installer as a
post-install step. This script adjusts
all paths in the above CMake files from the build directory to the
installation directory. It also adjusts the
host name contained in DartConfiguration.tcl, so the results show up in
CDash under the correct name.
The final step of the post-installation script is to call ctest with the
following arguments:
  ctest -T Test -T Submit --track Nightly
For this to work the environment variable CMAKE_ROOT is set to the
just-installed CMake share directory in the script.

This causes a simple installation, which can be done automatically via
cron or the Windows task planner, to perform
the installation, carry out the tests and submit the results to CDash.
The only requirement for the test machines
is to have standard software installed, we need perl and python for our
tests.

Hope this helps,

Martin


On 05/30/10 14:17, Alexander Neundorf wrote:
> On Friday 28 May 2010, Martin Apel wrote:
>   
>> Hi Karthik,
>>
>> I was aware, that I can start ctest this way. However from my
>> understanding this requires at least the whole build tree to be at the
>> same location
>> as on the build machine. I had hoped to get away with copying a subset
>> of the generated files somehow, possibly to a different directory.
>> 
> Yes, I'm interested in the same thing.
> I'd like to run our tests on different cluster sizes. It's the same compiler,
> OS and hardware each time, "just" a different number of nodes where it will
> run on.
> I guess one should look at the testing files created in the buildtree and then
> figure out what could be done.
>
> Alex
>
>   


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build on one machine, test on multiple

[Martin Apel]

Hi Karthik,

I was aware, that I can start ctest this way. However from my
understanding this requires at least the whole build tree to be at the
same location
as on the build machine. I had hoped to get away with copying a subset
of the generated files somehow, possibly to a different directory.

Regards,

Martin

On 05/28/10 09:05, Karthik Krishnan wrote:
> On Fri, May 28, 2010 at 12:04 PM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
>
> Hi Alok,
>
> the problem is not to start the testing process remotely. In my
> case it's no problem simply setting up the Windows task planner to
> execute some script every night. The problem is more, how do I
> tell ctest to perform its tests without having to perform the
> complete build as well.
>
>
> Explicitly tell ctest to perform just the specific actions..
>
>   ctest -T Test -T Submit
>
> will perform just the test and submit parts. Equivalent line within
> your CTest script would be something like
>
> SET (CTEST_COMMAND 
>   "C:/Program Files/CMake/bin/ctest.exe -T Test -T Submit"
>   )
>   
>
>
>


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Build on one machine, test on multiple

[Martin Apel]

Hi Alok,

the problem is not to start the testing process remotely. In my case
it's no problem simply setting up the Windows task planner to execute
some script every night. The problem is more, how do I tell ctest to
perform its tests without having to perform the complete build as well.
I would probably need to copy both the complete source as well as the
binary directory from the build to the test machines and then have a
ctest script execute only the test and submit steps. For the binary
directory to be usable this would either require the directories being
under the same path on all machines or to modify the files in the build
directory somehow, so the paths are correct with respect to the test
machine.

Regards,

Martin

On 05/27/10 22:12, Alok Govil wrote:
> Hi Martin,
>
> This is of interest to me as well.  Please let me know what you find.
>
> Here are two ways I could find to start a task on a remote Windows
> computer:
>
> http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
> I do not know if the return code from the executable will be
> passed back by this utility.
>
>
> http://motevich.blogspot.com/2007/11/execute-program-on-remote-computer.html
> This seems to pass the return code back from the remote
> executable.  Requires a script
> to run however, so I would prefer #1 if it solves the issue.
>
> I wonder if there is a platform independent way of doing this.
>
> Thanks,
>
> Alok
>
> > Date: Thu, 27 May 2010 14:41:11 +0200
> > From: martin.a...@simpack.de
> > To: cmake@cmake.org
> > Subject: [CMake] Build on one machine, test on multiple
> >
> > Hi all,
> >
> > we have currently set up a nightly build process, which builds and tests
> > our software via CMake / CTest and submits results to CDash.
> > However I would like run some tests on multiple machines with different
> > OS versions (Windows XP, Vista, Windows 7) for a build, which has been
> > created under Windows XP on a single machine. That means I explicitly
> > don't want to build the software on each machine, that it is tested on.
> > Has anybody else tried such a thing using CMake and CTest? If you have
> > any ideas on how to approach this, please let me know.
> >
> > Martin
> >
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
>
> ----
> The New Busy is not the too busy. Combine all your e-mail accounts
> with Hotmail. Get busy.
> <http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4>


-- 

Martin Apel
Software Architect  
Phone:   + 49 8105 77266-53
E-Mail:  martin.a...@simpack.de

SIMPACK AG
Friedrichshafener Strasse 1, 82205 Gilching, Germany
i...@simpack.de, www.simpack.com
Phone: + 49 8105 77266-0
Fax:   + 49 8105 77266-11


Executive Board: Dr. Alexander Eichberger, Dr. Lutz Mauer
Chair of Supervisory Board: Silvia Förster (CPA)
Commercial Register München HRB 181 229

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Build on one machine, test on multiple

[Martin Apel]

Hi all,

we have currently set up a nightly build process, which builds and tests
our software via CMake / CTest and submits results to CDash.
However I would like run some tests on multiple machines with different
OS versions (Windows XP, Vista, Windows 7) for a build, which has been
created under Windows XP on a single machine. That means I explicitly
don't want to build the software on each machine, that it is tested on.
Has anybody else tried such a thing using CMake and CTest? If you have
any ideas on how to approach this, please let me know.

Martin

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CTest ignoring custom set variables

[Martin Apel]

David Cole wrote:
> On Fri, Dec 11, 2009 at 3:58 AM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
>
> Hi all,
>
> I tried to set some CTest custom variables such as
> CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE in the CTestCustom.cmake
> file in the binary directory.
> This works as long as I run ctest interactively, e.g. "ctest -D
> Experimental". In this case, the test output is not cut off. If I
> do the
> same using a CTest script, it seems the CTestCustom.cmake file
> is completely ignored, so the test output is cut off at the default
> value of 1024 characters.
>  Is this intended behaviour or is it a bug?
>
>
> Probably a little bit of each... 
>
> Try putting a call to:
> CTEST_READ_CUSTOM_FILES("${CTEST_BINARY_DIRECTORY}")
>
> after ctest_configure and before ctest_build...
>
> One could certainly make the argument that this should be entirely
> invisible and automatic and buried inside the ctest_configure call. In
> that sense, it's a bug.
>
> I know the author of the ctest_read_custom_files command intended
> things to be this way, but I still do not understand why... Perhaps if
> nobody can explain why it should be left this way, it would make sense
> to try to make this implied/automatic at the end of a ctest_configure
> command
>
>
> HTH,
> David
Hi David,

thanks a lot, this did the trick.

Regards,

Martin
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CTest ignoring custom set variables

[Martin Apel]

Hi all,

I tried to set some CTest custom variables such as
CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE in the CTestCustom.cmake
file in the binary directory.
This works as long as I run ctest interactively, e.g. "ctest -D
Experimental". In this case, the test output is not cut off. If I do the
same using a CTest script, it seems the CTestCustom.cmake file
is completely ignored, so the test output is cut off at the default
value of 1024 characters.
 Is this intended behaviour or is it a bug? It seems to work, if I enter
the variable settings into the script file, but that's not the way its
documented to work.

Regards,

Martin


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug in Cmake --system-information

[Martin Apel]

Dixon, Shane wrote:
> I'm running Cmake 2.8.0-rc3.  Running "cmake --system-information" doesn't 
> dump anything, but tries to build in the current directory.  This seems like 
> a bug.  If anyone else can confirm this, I'll open a bug report for it.
>
> --
> Shane Dixon
> Linux Engineer
> Atmel Corporation
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>   
I tried this on my Linux machine and it works as expected. So it
probably has to be some problem with your environment.

Martin

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_SYSTEM not available

[Martin Apel]

Philip Lowman wrote:
> On Wed, Sep 30, 2009 at 5:24 AM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
>
> I had a similar issue with CMAKE_SYSTEM_NAME. I have put platform
> specific default settings into files called "Linux.cmake" and
> "Windows.cmake",
> where the file is included as
>   INCLUDE (${CMAKE_SYSTEM_NAME}.cmake)
>
> However it's not possible to initialize some variables, because
> this include statement has to be after the PROJECT command.
> I tried to set CMAKE_EXE_LINKER_FLAGS_INIT inside these
> platform-specific files, but it seems that it's too late to set
> them after
> the PROJECT command. So I have a cycle:
> - I cannot use the above include statement before the PROJECT call
> - but if I use it after the PROJECT call I cannot set some
> variables anymore (I can set them, but they have no effect,
> because in the above example
>   CMAKE_EXE_LINKER_FLAGS is initialized from
> CMAKE_EXE_LINKER_FLAGS_INIT during the PROJECT call)
>
> Currently I work around this by not setting
> CMAKE_EXE_LINKER_FLAGS_INIT, but CMAKE_EXE_LINKER_FLAGS inside my
> Linux.cmake. This used to work fine with CMake 2.6, but 2.8 issues
> a warning, that I am overwriting a cached variable.
>
> What is the recommended way to initialize platform-specific flags,
> which are held in the cache?
>
>
> You are correct that conditionals don't work prior to project() in the
> toplevel file but they seem to work fine within the platform override
> .cmake file itself.  You might try having one flags file with whatever
> conditionals you need for Linux, Windows, etc.
>
> For example:
> http://www.cmake.org/Wiki/CMake_FAQ#Make_Override_Files
> 
>
> -- 
> Philip Lowman
Hi Philip,

thanks for the info. This did the trick.

Martin

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMAKE_SYSTEM not available

[Martin Apel]

I had a similar issue with CMAKE_SYSTEM_NAME. I have put platform
specific default settings into files called "Linux.cmake" and
"Windows.cmake",
where the file is included as
  INCLUDE (${CMAKE_SYSTEM_NAME}.cmake)

However it's not possible to initialize some variables, because this
include statement has to be after the PROJECT command.
I tried to set CMAKE_EXE_LINKER_FLAGS_INIT inside these
platform-specific files, but it seems that it's too late to set them after
the PROJECT command. So I have a cycle:
- I cannot use the above include statement before the PROJECT call
- but if I use it after the PROJECT call I cannot set some variables
anymore (I can set them, but they have no effect, because in the above
example
  CMAKE_EXE_LINKER_FLAGS is initialized from CMAKE_EXE_LINKER_FLAGS_INIT
during the PROJECT call)

Currently I work around this by not setting CMAKE_EXE_LINKER_FLAGS_INIT,
but CMAKE_EXE_LINKER_FLAGS inside my Linux.cmake. This used to work fine
with CMake 2.6, but 2.8 issues a warning, that I am overwriting a cached
variable.

What is the recommended way to initialize platform-specific flags, which
are held in the cache?

Regards,

Martin

Dieter Oberkofler wrote:
> Nothing wrong with calling project at the very beginning but in my case it
> was quite at the end of the CMakeLists.txt file and this made it fail. I was
> not aware of this "restriction" until now and did also not find any remarks
> in the documentation.
>
>   
>> -Original Message-
>> From: Tyler Roscoe [mailto:ty...@cryptio.net]
>> Sent: Tuesday, September 29, 2009 19:45
>> To: Dieter Oberkofler
>> Cc: cmake@cmake.org
>> Subject: Re: [CMake] CMAKE_SYSTEM not available
>>
>> On Tue, Sep 29, 2009 at 07:42:09PM +0200, Dieter Oberkofler wrote:
>> 
>>> The installation looks ok but I guess I just found out what is wrong.
>>> CMAKE_SYSTEM is only available after having used the PROJECT command.
>>> Is this really a needed and required dependency?
>>>   
>> Is there some reason you want to avoid calling project()?
>>
>> project() sets up a bunch of stuff. I guess you could try to call all
>> the relevant CMake modules yourself, but just putting a project(tmp) at
>> the top of your CMakeLists seems like a pretty good solution to me.
>>
>> tyler
>> 
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
>   


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [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
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.0 RC 1 ready for testing!

[Martin Apel]

Hi all,

thanks for your efforts to improve CMake. Especially the support to run
tests in parallel is really great!
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, which in turn calls xild
and this step takes ages (about one minute).
I know that Intel recommends to use xiar instead of ar, but it used
to work for us to use ar, which is
much faster (about 3 seconds). This is an issue which might keep us
from upgrading to 2.8, so it would be nice to have a
way to restore the old behaviour or to tune the xiar call.
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? Or can I tell CMake not to add any additional
compiler libraries?

Apart from these two issues, it works great for me. Until now I only
tested it on Linux, but I will check on Windows as well.

Regards,

Martin

Bill Hoffman wrote:
> I am happy to announce that CMake 2.8.0 has entered the beta stage! You
> can find the source and binaries here: http://www.cmake.org/files/v2.8/.
>
> I am sure I am leaving something out, but here is the list of changes
> that I came up with.  (If you notice something missing please let me
> know and I will add it to the official release when 2.8.0 is finalized.)
> Changes in CMake 2.8.0 RC 1
>
> - Qt based GUI cmake-gui is now the default GUI, MFC CMakeSetup is no
>longer included in CMake.  ccmake is still supported.
> - cmake-gui supports multi-state values options.
> - CMake now has cmake --build command that can build any CMake generated
>project from the command line.
> - Visual Studio 2010 beta support has been added.
> - Significant improvements for the Eclipse project generator (all
>targets are now available in Eclipse, system include dirs and
>predefined macros are now  detected so syntax highlighting works
>better)
> - KDevelop generator now has color output for builds, and non verbose
>makefiles.
> - CTest supports running tests in parallel with a -j N option.
> - A new CTest CTEST_USE_LAUNCHERS option can be used to get better
>dashboard error reports with make based tools.
> - CTest has support for sub-projects and labels which can interact
>with CDash.
> - CTest now supports Git, Mercurial, and Bazaar.
> - It is now possible to use DESTDIR in CPack for any CMake based projects
>giving more flexibility on the final path names.
> - The CPack Deb generator now computes the arch instead of hard coding it.
> - Fortran/C mixed language projects made much easier. CMake now
>automatically can compute the run time libraries for a compiler. In
>addition, a new FortranCInterface module can determine the correct
>name mangling needed to mix C and Fortran.
> - Intel compiler support added to OSX, and support for embedded
>manifests in the windows intel compiler was added.
> - Depend scanning is now much faster with makefiles.
> - Many FindQt4 improvements to stay working with current Qt releases
> - FindMPI has improvements for windows.
> - FindRuby.cmake now supports Ruby 1.9
> - FindBoost has been updated to work with the most recent boost releases.
> - New External Project Module.  The 'ExternalProject_Add' function
>creates a custom target to drive download, update/patch, configure,
>build, install and test steps of an external project.
> - xmlrpc dependancy has been removed
> - CMAKE_OSX_DEPLOYMENT_TARGET cache variable has been created to set the
>deployment OS for a build on OSX.
> - Several new policies were added:
>CMP0012
> The if() command can recognize named boolean constants.
>CMP0013
> Duplicate binary directories are not allowed.
>CMP0014
> Input directories must have CMakeLists.txt.
>CMP0015
> The set() CACHE mode and option() command make the cache value
> visible.
> - Lots of bug fixes.
>
>
> Please try this version of CMake on your projects and report any issues
> to the list or the bug tracker ( I have added a CMake-2-8 version ).
>
> Happy, building!
>
> -Bill
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake 

[CMake] Strange problem with build running twice from ctest script on Windows

[Martin Apel]

Hi all,

I am experiencing a very strange problem with a build run via a ctest
script on Windows. The script looks as follows:

SET (CTEST_SOURCE_DIRECTORY "C:/s_9XXX_build-windows-32/develop")
SET (CTEST_PROJECT_NAME "Spck NA")
SITE_NAME(CTEST_SITE)
SET(CTEST_BUILD_NAME win32-plain-Experimental)
SET (CTEST_BINARY_DIRECTORY "C:/s_9XXX_build-windows-32/obj/plain32")
SET (CTEST_TEST_TIMEOUT 3600)
SET (CTEST_BUILD_COMMAND "nmake -i world")
SET (CTEST_CONFIGURE_COMMAND
"C:/s_9XXX_build-windows-32/develop/extern/win32/cmake-2.6/bin/cmake
-DCMAKE_BUILD_TYPE=Debug -G \"NMake Makefiles\" ${CTEST_SOURCE_DIRECTORY}")
ctest_empty_binary_directory("${CTEST_BINARY_DIRECTORY}")
ctest_start(Experimental)
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_build(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_test(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_submit()

The result of running this via 'ctest --debug -VV -S' is, that the build
and test is carried out twice. After the first submission to CDash the
following error message appears in the log output generated by ctest:
  C:\ma\cmake\cmake-2.6.4\Source\CTest\cmCTestScriptHandler.cxx:411
Error in read script:
E:/simbuild/s_9XXX_build-windows-32/new_arch.Nightly.32.opt.ctest

Some of the tests invoked during the test step are failing, but I
expect, that ctest should not run the script twice, if any of the tests
are failing.
Afterwards the build is started all over, after the second run the same
message appears, but the ctest invocation terminates. On Linux the same
script works correctly without any errors.

I played around a bit and found out, that by removing the line
containing 'ctest_test' in the above script, the script would only be
run once without errors.
I also tried running the script in a separate process, using 'ctest -SP'
instead of 'ctest -S'. This also leads to a build running once only. For
me this means, that it works now using 'ctest -SP',  but to me it looks
like a bug in CTest.

Regards,

Martin



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting up a PGO sequence

[Martin Apel]

Hi,

I think you should be able to do something like the following:

set(CMAKE_C_FLAGS  ${CMAKE_C_FLAGS})   # For CXX
probably as well
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_build(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_test(BUILD "${CTEST_BINARY_DIRECTORY}" )

set(CMAKE_C_FLAGS  ${CMAKE_C_FLAGS})   # For CXX
probably as well
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_build(BUILD "${CTEST_BINARY_DIRECTORY}" )

I haven't tried this out, but I don't see any reason, why this should
not work.

Regards,

Martin


night owl03d wrote:
> I am trying to figure out the best way to set up CMake to do release
> builds with profile guided optimization for gcc and msvc.
>
> The general sequence I want to perform is...
>
> 1. Build with instrumentation.
> 2. Run training apps.
> 3. rebuild with pgo. (In gcc this is a clobber build, and in msvc it
> is just a relink).
>
> My best guess is that I want to do the build, configure ctest to run
> my training apps, and then redo the build. Well 1 and 2 is easy, but I
> am trying to figure out how to arrange for 3 to be fired off without
> manual intervention. I am sure there is an easy way to do it, but I am
> brain farting on it right now.
>
> I have used scons to do this sort of thing before, but I can't figure
> out how to make it work with cmake.
>
>
>
>
>
>


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] visual studio parallel build

[Martin Apel]

j s wrote:
> I don't think so, but this article claims that by specifying multiple
> c++ files at the same time, the Visual C++ compiler will parallelize them:
>
> http://stackoverflow.com/questions/601970/how-do-i-utilise-all-the-cores-for-nmake
> 
>
> Regards,
As nmake cannot perform parallel builds on its own, it would be nice, if
CMake could use the possibility of the cl compiler itself to compile
multiple files in parallel.
Qt's qmake does this by creating a temporary file containing a single cl
invocation with multiple names of source files to be built. Wouldn't it
be possible for the NMake generator to
perform something similar?

Regards,

Martin
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Cdash] Setting up weekly tests using ctest

[Martin Apel]

Hi David,

I tried this out, it works like a charm. So easy!

Thanks a lot.

Martin

David Cole wrote:
> Make a "Weekly" build group for your CDash project. Name your builds
> according to some naming convention that makes sense to you
> (distinct/unique compared to the "Nightly" builds), and then simply
> assign those build names from those sites to the "Weekly" group.
>
> Let me know if you need more info : it should be really
> straightforward if you are the CDash project administrator.
>
>
> HTH,
> David
>
>
> On Fri, Jul 10, 2009 at 5:05 AM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
>
> Hi Dan,
>
> that's what we do for nightly tests as well. The problem is more:
> How do I tell CTest to submit tests to a separate "weekly" track
> and have them visible in CDash separated from the nightly tests?
>
> Martin
>
>
> Dan Schmidt wrote:
>> Hey Martin,
>>
>> How about scheduling the type of test that you'd like to run with
>> the OS scheduler. We run tests every couple of hours and do it
>> with the Unix crontab and the Windows task scheduler.
>>
>> --
>> Dan
>>
>> > Date: Fri, 10 Jul 2009 09:46:13 +0200
>> > From: martin.a...@simpack.de <mailto:martin.a...@simpack.de>
>> > To: cd...@public.kitware.com <mailto:cd...@public.kitware.com>;
>> cm...@cmake..org <mailto:cm...@cmake..org>
>> > Subject: [Cdash] Setting up weekly tests using ctest
>> >
>> > Hi there,
>> >
>> > I am currently running nightly builds and accompanying tests
>> using CMake
>> > and CDash. However, our software is rather computationally
>> expensive, so
>> > we'd like to perform more extensive tests every weekend,
>> because one
>> > night is too short for these. I only found documentation on
>> setting up
>> > nightly, experimental and continuous builds (and tests), but not
>> > arbitrary, e.g. weekly tests. I tried to explicitly set the --track
>> > option of ctest to "Weekly", which succeeded, but the tests
>> didn't show
>> > up in CDash. Can anybody tell me, how to set up tests
>> > for weekly intervals?
>> >
>> > Martin
>> >
>> >
>> >
>> > 
>> > Virus checked by G DATA AntiVirus
>> > Version: AVA 19.6409 from 10.07.2009
>>     >
>> >
>> > ___
>> > Cdash mailing list
>> > cd...@public.kitware.com <mailto:cd...@public.kitware.com>
>> > http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>> 
>>
>> 
>> check out the rest of the Windows Live™. More than mail–Windows
>> Live™ goes way beyond your inbox. More than messages
>
>
> -- 
>
> Martin Apel Tel: 0049 8153 9288-47
> Software Architect  E-Mail:  
> martin.a...@simpack.de <mailto:martin.a...@simpack.de>
>
> INTEC GmbH  Tel: 0049 8153 9288-0
> Argelsrieder Feld 13Fax: 0049 8153 9288-11
> 82234 Wessling  E-Mail:  in...@simpack.de 
> <mailto:in...@simpack.de>
> Germany     URL: 
> http://www.simpack.com 
> 
>
>
> 
> Virus checked by G DATA AntiVirus
> Version: AVA 19.6410 from 10.07.2009
>
>
> ___
> Powered by www.kitware..com 
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> 
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> 
>
>


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  martin.a...@simpack.de

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  in...@simpack.de
Germany URL: http://www.simpack.com



Virus checked by G DATA AntiVirus
Version: AVA 19.6413 from 10.07.2009

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [Cdash] Setting up weekly tests using ctest

[Martin Apel]

Hi Dan,

that's what we do for nightly tests as well. The problem is more: How do
I tell CTest to submit tests to a separate "weekly" track and have them
visible in CDash separated from the nightly tests?

Martin

Dan Schmidt wrote:
> Hey Martin,
>
> How about scheduling the type of test that you'd like to run with the
> OS scheduler. We run tests every couple of hours and do it with the
> Unix crontab and the Windows task scheduler.
>
> --
> Dan
>
> > Date: Fri, 10 Jul 2009 09:46:13 +0200
> > From: martin.a...@simpack.de
> > To: cd...@public.kitware.com; cm...@cmake..org
> > Subject: [Cdash] Setting up weekly tests using ctest
> >
> > Hi there,
> >
> > I am currently running nightly builds and accompanying tests using CMake
> > and CDash. However, our software is rather computationally expensive, so
> > we'd like to perform more extensive tests every weekend, because one
> > night is too short for these. I only found documentation on setting up
> > nightly, experimental and continuous builds (and tests), but not
> > arbitrary, e.g. weekly tests. I tried to explicitly set the --track
> > option of ctest to "Weekly", which succeeded, but the tests didn't show
> > up in CDash. Can anybody tell me, how to set up tests
> > for weekly intervals?
> >
> > Martin
> >
> >
> >
> > 
> > Virus checked by G DATA AntiVirus
> > Version: AVA 19.6409 from 10.07.2009
> >
> >
> > ___
> > Cdash mailing list
> > cd...@public.kitware.com
> > http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>
> 
> check out the rest of the Windows Live™. More than mail–Windows Live™
> goes way beyond your inbox. More than messages
> 


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  martin.a...@simpack.de

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  in...@simpack.de
Germany URL: http://www.simpack.com



Virus checked by G DATA AntiVirus
Version: AVA 19.6410 from 10.07.2009

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Setting up weekly tests using ctest

[Martin Apel]

Hi there,

I am currently running nightly builds and accompanying tests using CMake
and CDash. However, our software is rather computationally expensive, so
we'd like to perform more extensive tests every weekend, because one
night is too short for these. I only found documentation on setting up
nightly, experimental and continuous builds (and tests), but not
arbitrary, e.g. weekly tests. I tried to explicitly set the --track
option of ctest to "Weekly", which succeeded, but the tests didn't show
up in CDash. Can anybody tell me, how to set up tests
for weekly intervals?

Martin




Virus checked by G DATA AntiVirus
Version: AVA 19.6409 from 10.07.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] problem : cmake 2.6.4 intel fortran compiler 11 - visstudio 2008

[Martin Apel]

Hi John,

the same problem has bitten me as well, now in a case, where I cannot
simply uninstall one of both compiler versions.
I analyzed the situation a bit, and I am not sure, if either CMake or
Visual Studio is the culprit here.
During try_compile for checking the Fortran compiler, CMake generates a
VisualFortran project file, which contains a version number "9.10".
According to the CMake source code, this is a fixed version number, it
does not depend on the version of the compiler found in any way.

With only one Fortran compiler installed, Visual Studio loads this
project file without problems. When multiple Fortran compilers are
installed,
loading this project file interactively triggers a message box,
indicating that the project file has to be converted.
I'm not sure, if this is a bug in Visual Studio and/or if CMake can do
anything about it. I assume, that CMake could pass the "/upgrade" flag
to devenv,
when calling it in this case, so the project would hopefully be upgraded
automatically, if necessary.
Anyway this is what causes the initial CMake step to fail, if multiple
Intel Fortran versions are installed.

Thanks,

Martin

John Biddiscombe wrote:
> I've been reading through the archives and followed instructions therein
> and am getting the following error (below)
> I've setup the ifort batch environment and all seems fine, but it looks
> as though devenv is being called with the wrong command line.
> Run Build Command:C:\PROGRA~1\MICROS~1.0\Common7\IDE\devenv.com
> CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec
>
> Is there a simple fix?
>
> thanks
>
> JB
>
>
> D:\cmakebuild\mhd\CMakeFiles\CMakeTmp>cmake -G "Visual Studio 9 2008"
> D:/Code/CSCS/run_nuprox_hybrid --debug-trycompile
> debug trycompile on
> -- Check for working Fortran compiler: C:/Program
> Files/Intel/Compiler/11.0/074/fortran/Bin/IA32/ifort.exe
> -- Check for working Fortran compiler: C:/Program
> Files/Intel/Compiler/11.0/074/fortran/Bin/IA32/ifort.exe -- broken
> CMake Error at C:/Program
> Files/cmake-2.6.4/share/cmake-2.6/Modules/CMakeTestFortranCompiler.cmake:25
> (MESSAGE):
>   The Fortran compiler "C:/Program
>   Files/Intel/Compiler/11.0/074/fortran/Bin/IA32/ifort.exe" is not able to
>   compile a simple test program.
>
>   It fails with the following output:
>
>Change Dir: D:/cmakebuild/mhd/CMakeFiles/CMakeTmp/CMakeFiles/CMakeTmp
>
>
>
>   Run Build Command:C:\PROGRA~1\MICROS~1.0\Common7\IDE\devenv.com
>   CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec
>
>
>
>   Microsoft (R) Visual Studio Version 9.0.30729.1.
>
>   Copyright (C) Microsoft Corp.  All rights reserved.
>
>
>
>   Invalid project
>
>
>
>   Use:
>
>   devenv [solutionfile | projectfile | anyfile.ext] [switches]
>
>
>
>   The first argument for devenv is usually a solution file or project file.
>
>   You can also use any other file as the first argument if you want to have
>   the
>
>   file open automatically in an editor.  When you enter a project file, the
>   IDE
>
>   looks for an .sln file with the same base name as the project file in the
>
>   parent directory for the project file.  If no such .sln file exists, then
>   the
>
>   IDE looks for a single .sln file that references the project.  If no such
>   single
>
>   .sln file exists, then the IDE creates an unsaved solution with a default
>   .sln
>
>   file name that has the same base name as the project file.
>
>
>
>   Command line builds:
>
>   devenv solutionfile.sln /build [ solutionconfig ] [ /project
>   projectnameorfile [ /projectconfig name ] ]
>
>   Available command line switches:
>
>
>
>   /BuildBuilds the solution or project with the
> specified solution
>
> configuration.  For example "Debug".  If multiple platforms
>
> are possible, the configuration name must be enclosed in
> quotes
>
> and contain platform name.  For example: "Debug|Win32".
>
>   /CleanDeletes build outputs.
>
>   /Command  Starts the IDE and executes the command.
>
>   /Deploy   Builds and then deploys the specified build
> configuration.
>
>   /Edit Opens the specified files in a running instance of this
>
> application.  If there are no running instances, it will
>
> start a new instance with a simplified window layout.
>
>   /LCID Sets the default language in the IDE for the UI.
>
>   /Log  Logs IDE activity to the specified file for troubleshooting.
>
>   /NoVSIP   Disables the VSIP developer's license key for
> VSIP testing.
>
>   /Out  Appends the build log to a specified file.
>
>   /Project  Specifies the project to build, clean, or deploy.
>
> Must be used with /Build, /Rebuild, /Clean, or /Deploy.
>
>   /ProjectConfigOverrides the project configuration specified in the
>   solution
>
> configuration.  For example "Debug".  If multiple
> platforms are
>
>  

Re: [CMake] problem : cmake 2.6.4 intel fortran compiler 11 - visstudio 2008

[Martin Apel]

ied configuration.
>
>   /ResetAddin   Removes commands and command UI associated with the
> specified
>   Add-in.
>
>   /ResetSettingsRestores the IDE's default settings, optionally
> resets to
>
> the specified VSSettings file.
>
>   /ResetSkipPkgsClears all SkipLoading tags added to VSPackages.
>
>   /Run  Compiles and runs the specified solution.
>
>   /RunExit  Compiles and runs the specified solution then closes the
> IDE.
>
>   /SafeMode Launches the IDE in safe mode loading minimal windows.
>
>   /Upgrade  Upgrades the project or the solution and all projects in it.
>
> A backup of these files will be created as appropriate.
> Please
>
> see Help on 'Visual Studio Conversion Wizard' for more
>
> information on the backup process.
>
>
>
>   Product-specific switches:
>
>
>
>   /debugexe Open the specified executable to be debugged.  The
>
> remainder of the command line is passed to this
>
> executable as its arguments.
>
>   /useenv   Use PATH, INCLUDE, LIBPATH, and LIB environment
> variables
>
> instead of IDE paths for VC++ builds.
>
>
>
>   To attach the debugger from the command line, use:
>
> VsJITDebugger.exe -p 
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:1 (PROJECT)
>
>
> CMake Warning (dev) in CMakeLists.txt:
>   No cmake_minimum_required command is present.  A line of code such as
>
> cmake_minimum_required(VERSION 2.6)
>
>   should be added at the top of the file.  The version specified may be
> lower
>   if you wish to support older CMake versions for this project.  For more
>   information run "cmake --help-policy CMP".
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Configuring incomplete, errors occurred!
>
> --
> John Biddiscombe,email:biddisco @ cscs.ch
> http://www.cscs.ch/
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> Via Cantonale, 6928 Manno, Switzerland  | Fax:  +41 (91) 610.82.82
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> .
>
>   


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  martin.a...@simpack.de

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  in...@simpack.de
Germany URL: http://www.simpack.com


Virus checked by G DATA AntiVirus
Version: AVA 19.6133 from 26.06.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Emacs: Addition to cmake-model.el to show cmake documentation

[Martin Apel]

Hi James,

your version for showing documentation is surely much nicer than mine.
One minor tip: Instead of your function cmake-find-word you could use
the function word-at-point coming from the package thingatpt, which does
exactly, what you need. This package is part of the current Emacs
distribution.

Best Regards,

Martin

James Bigler wrote:
> On Tue, Apr 28, 2009 at 8:21 AM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
> > Bill Hoffman wrote:
> >> Martin Apel wrote:
> >>
> >>> Hi all,
> >>>
> >>> Inspired by the Emacs command cperl-perldoc-at-point I wrote a little
> >>> command to show the CMake documentation of the command on which the
> >>> cursor is currently positioned. It will open another buffer and
> show the
> >>> documentation generated from "cmake --help-command " in that
> >>> buffer. I found it very useful during creating CMakeLists.txt files.
> >>>
> >>> Bill, maybe it makes sense to integrate this into cmake-mode.el?
> >>>
> >>>
> >>
> >> Looks neat.  Is there a better way in emacs to set the path to CMake?
> >> On many systems I do not put cmake into the PATH.
> >>
> >> -Bill
> >>
> >>
> > You could probably make it a variable, which would be settable through
> > the customize interface of Emacs. I will look into it
> > and repost it, when it's done.
> >
> > Martin
> >
>
> This is pretty lean.  I wrote something similar that I was testing.
>
> Some features:
>
> 1. Provides a default argument, but allows you type in something
> different.
> 2. Maintains a history of the arguments you have given.
> 3. Allows you to run an arbitrary cmake command and put the output
> into a named buffer.
> 4. Runs the cmake command in the back.
> 5. cmake executable is a customized variable.
>
> James
>
> (defun cmake-find-word ()
>  "Finds the word on your cursor."
>  (interactive)
>  (let (word)
>(save-excursion
>  ;; Find the end of the word
>  (forward-word)
>  (let ((end (point)))
>;; Find the beginning
>(backward-word)
>;; Set the word
>(setq word (buffer-substring-no-properties (point) end))
>)
>  )
>)
>  )
>
> (defcustom cmake-mode-cmake-executable "cmake"
>   "*The name of the cmake executable.
> This can be either absolute or looked up on `exec-path'."
>   ;; Don't use (file :must-match t).  It doesn't know about `exec-path'.
>   :type 'file
>   :group 'cmake)
>
> (defun cmake-command-run (type &optional topic)
>  "Runs the command cmake with the arguments specified.  The
> optional argument topic will be appended to the argument list."
>  (interactive "s")
>  (let* ((bufname (concat "*CMake" type (if topic "-") topic "*"))
> (buffer  (get-buffer bufname))
> )
>(if buffer
>(display-buffer buffer 'not-this-window)
>  ;; Buffer doesn't exist.  Create it and fill it
>  (setq buffer (generate-new-buffer bufname))
>  (setq command (concat cmake-mode-cmake-executable " " type " "
> topic))
>  (message "Running %s" command)
>  (shell-command command buffer)
>  ;; Save the original window, so that we can come back to it later.
>  ;; save-excursion doesn't seem to work for this.
>  (setq window (selected-window))
>  ;; We need to select it so that we can apply special modes to it
>  (select-window (display-buffer buffer 'not-this-window))
>  (cmake-mode)
>  (toggle-read-only t)
>  ;; Restore the original window
>  (select-window window)
>  )
>)
>  )
>
> (defun cmake-help-list-commands ()
>  "Prints out a list of the cmake commands."
>  (interactive)
>  (cmake-command-run "--help-command-list")
>  )
>
> (defvar cmake-help-command-history nil "Topic read history.")
>
> (defun cmake-get-topic (type)
>  "Gets the topic from the minibuffer input.  The default is the word
> the cursor is on."
>  (interactive)
>  (let* ((default-entry (cmake-find-word))
> (input (read-string
> (format "CMake %s (default %s): " type default-entry)
> ; prompt
> nil ; initial input
> 'cmake-help-command-history ; command history
> default-entry ; default-value
> )))
>(if (string= input "")
>(error &q

Re: [CMake] Emacs: Addition to cmake-model.el to show cmake documentation

[Martin Apel]

Bill Hoffman wrote:
> Martin Apel wrote:
>   
>> Hi all,
>>
>> Inspired by the Emacs command cperl-perldoc-at-point I wrote a little
>> command to show the CMake documentation of the command on which the
>> cursor is currently positioned. It will open another buffer and show the
>> documentation generated from "cmake --help-command " in that
>> buffer. I found it very useful during creating CMakeLists.txt files.
>>
>> Bill, maybe it makes sense to integrate this into cmake-mode.el?
>>
>> 
>
> Looks neat.  Is there a better way in emacs to set the path to CMake?
> On many systems I do not put cmake into the PATH.
>
> -Bill
>
>   
You could probably make it a variable, which would be settable through
the customize interface of Emacs. I will look into it
and repost it, when it's done.

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.356 from 27.04.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Emacs: Addition to cmake-model.el to show cmake documentation

[Martin Apel]

Hi all,

Inspired by the Emacs command cperl-perldoc-at-point I wrote a little
command to show the CMake documentation of the command on which the
cursor is currently positioned. It will open another buffer and show the
documentation generated from "cmake --help-command " in that
buffer. I found it very useful during creating CMakeLists.txt files.

Bill, maybe it makes sense to integrate this into cmake-mode.el?

Regards,

Martin




Virus checked by G DATA AntiVirus
Version: AVF 19.356 from 27.04.2009

(require 'thingatpt)
(defun cmake-doc (word)
  "Generate cmake documentation on WORD."
  (interactive
   (list (let* ((default-entry (word-at-point))
(input (read-string
(format "doc entry%s: "
(if (string= default-entry "")
""
  (format " (default %s)" default-entry))
   (if (string= input "")
   (if (string= default-entry "")
   (error "No doc args given")
 default-entry)
 input
  (shell-command (concat "cmake --help-command " word))
)

;;;###autoload
(defun cmake-doc-at-point ()
  "Run a `doc' on the word around point."
  (interactive)
  (cmake-doc (word-at-point)))


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Analyze file dependencies in Visual Studio for projectgeneratedbyCMake

[Martin Apel]

Alexander Neundorf wrote:
> On Thursday 23 April 2009, Martin Apel wrote:
>   
>> Alexander Neundorf wrote:
>> 
>>> On Wednesday 22 April 2009, Martin Apel wrote:
>>>   
>>>> Hi all,
>>>>
>>>> I am currently fighting with Visual Studio regenerating a
>>>> CMake-generated project on every build, although nothing has changed. I
>>>> am searching for a method how to debug the generated dependencies inside
>>>> VS. The project builds a DLL from Fortran files, which are generated by
>>>> a Perl script. The setup looks something like this:
>>>>
>>>> ADD_CUSTOM_COMMAND(OUTPUT ${FortranSources}
>>>>COMMAND ${CMAKE_COMMAND} -E chdir
>>>> ${CMAKE_CURRENT_BINARY_DIR} ${PERL_EXECUTABLE}
>>>> {CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
>>>>DEPENDS
>>>> ${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl FortranModules.inp
>>>> FortranCommons.inp ${ModuleDefs} ${CommonDefs})
>>>> ADD_LIBRARY(FortranInterface SHARED ${FortranSources}
>>>> FortranInterface.def)
>>>> 
>>> What is ModuleDefs and CommonDefs ? Are this files ?
>>> How does FortranSources look like ? Does it contain absolute paths ?
>>> I think you need to give a bit more information so that we can help.
>>>   
>> Hi Alex,
>>
>> thanks for your reply. ModuleDefs, CommonDefs and FortranSources are all
>> lists of files given with their absolute paths. createFortAccessors
>> parses the files listed in FortranModules.inp and FortranCommons.inp
>> given as input and produces the files listed in FortranSources as
>> output. I tried replacing FortranModules.inp and FortranCommons.inp with
>> their absolute paths (${CMAKE_CURRENT_SOURCE_DIR}, but this doesn't
>> change anything. Do you have any idea, what might be going wrong here?
>> 
>
> No, not really.
> I would suggest:
> -make sure that the paths are really correct, i.e. use full paths everywhere.
> Maybe the files are generated but they end up in a different directory ?
>
> If that doesn't help, try to strip the problem down as much as possible so
> that you get a minimal version which works and can reproduce which step makes
> it fail.
> You can start ass simple as using something like
> echo "hello" > ${outputfile}
> as your command to execute.
>
>   
Hi Alex,

I tried using full paths everywhere, it doesn't change anything. I even
checked the generated dependencies inside Visual Studio (they are
visible as custom build rule). All dependencies are correct and are
listed with full paths. Remember, the same build runs flawlessly on
Linux and with NMake.
I was more searching for a way, how to trace, why Visual Studio
regenerates a target, something along the lines of "gmake -d". I'm not
sure, that it's CMake's fault, it might be, that CMake is triggering a
bug in Visual Studio.

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.351 from 23.04.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Analyze file dependencies in Visual Studio for projectgeneratedby CMake

[Martin Apel]

Alexander Neundorf wrote:
> On Wednesday 22 April 2009, Martin Apel wrote:
>   
>> Hi all,
>>
>> I am currently fighting with Visual Studio regenerating a
>> CMake-generated project on every build, although nothing has changed. I
>> am searching for a method how to debug the generated dependencies inside
>> VS. The project builds a DLL from Fortran files, which are generated by a
>> Perl script. The setup looks something like this:
>>
>> ADD_CUSTOM_COMMAND(OUTPUT ${FortranSources}
>>COMMAND ${CMAKE_COMMAND} -E chdir
>> ${CMAKE_CURRENT_BINARY_DIR} ${PERL_EXECUTABLE}
>> {CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
>>DEPENDS
>> ${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl FortranModules.inp
>> FortranCommons.inp ${ModuleDefs} ${CommonDefs})
>> ADD_LIBRARY(FortranInterface SHARED ${FortranSources} FortranInterface.def)
>> 
>
> What is ModuleDefs and CommonDefs ? Are this files ?
> How does FortranSources look like ? Does it contain absolute paths ?
> I think you need to give a bit more information so that we can help.
>
>   
Hi Alex,

thanks for your reply. ModuleDefs, CommonDefs and FortranSources are all
lists of files given with their absolute paths. createFortAccessors
parses the files listed in FortranModules.inp and FortranCommons.inp
given as input and produces the files listed in FortranSources as
output. I tried replacing FortranModules.inp and FortranCommons.inp with
their absolute paths (${CMAKE_CURRENT_SOURCE_DIR}, but this doesn't
change anything. Do you have any idea, what might be going wrong here?

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.349 from 22.04.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Analyze file dependencies in Visual Studio for project generatedby CMake

[Martin Apel]

Hi all,

I am currently fighting with Visual Studio regenerating a
CMake-generated project on every build, although nothing has changed. I
am searching for a method how to debug the generated dependencies inside VS.
The project builds a DLL from Fortran files, which are generated by a
Perl script. The setup looks something like this:

ADD_CUSTOM_COMMAND(OUTPUT ${FortranSources}
   COMMAND ${CMAKE_COMMAND} -E chdir
${CMAKE_CURRENT_BINARY_DIR} ${PERL_EXECUTABLE}
{CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
   DEPENDS
${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl FortranModules.inp
FortranCommons.inp ${ModuleDefs} ${CommonDefs})
ADD_LIBRARY(FortranInterface SHARED ${FortranSources} FortranInterface.def)

Visual Studio regenerates the Fortran source files upon each build,
although none of the input files have changed. Any ideas how to find
out, why this happens, are very much appreciated.
The same project is generated correctly under Linux and even with a
nmake-based build.

Martin




Virus checked by G DATA AntiVirus
Version: AVF 19.347 from 21.04.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] fortran flags in a c++ linked executable

[Martin Apel]

James C. Sutherland wrote:
> Let me try this again.
>
> I have a f90 subroutine that performs file IO.  I would like to link
> that with a C++ driver.
>
> If I use a fortran driver, I am able to set the binary format via
> set( CMAKE_Fortran_FLAGS "-fconvert=big-endian" )
> This results in file IO in big-endian format.
>
> When using the C++ driver, (linking with g++), I cannot get things
> working properly.  I have tried various compiler settings:
>
> add_definitions( -Xlinker -fconvert=big-endian )  # links, 
> but does
> not affect endian-ness
> add_definitions( -Wl,-fconvert=big-endian )   # links, but does 
> not
> affect endian-ness
> add_definitions( -mbig-endian )  # does not work - link fails with
> unrecognized flag
>
> None of these result in an executable that properly handles big-endian
> file formats.
>
> The system I am compiling on is a little-endian system (intel Mac)
> with gfortran 4.4.0 and g++ 4.0.1.
>
>   
Hi James,

In general you can set linker options for your executable as follows:
  SET_TARGET_PROPERTIES( PROPERTIES LINK_FLAGS
"-Wl,--fconvert=big-endian")

As far as I know, --fconvert=big-endian is a compiler option not a
linker option, so this will not work.

But I don't think that this will succeed, because the man page of
gfortran contains the following comment:
-fconvert=conversion
   
   This option has an effect only when used in the main
program.  The "CONVERT" specifier and the GFORTRAN_CONVERT_UNIT
environment variable
   override the default specified by -fconvert.

As you probably don't have a Fortran main program, setting this option
will have no effect. In the end, you will have to find out, how to set
the conversion mode to use, if you don't have a Fortran main program. I
assume that you will have to explicitly select a library to link to your
program. Anyway, this is not a CMake issue.

Hope this helps,

Martin


Virus checked by G DATA AntiVirus
Version: AVB 19.282 from 31.03.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to surround an imported lib with extra flags onlink?

[Martin Apel]

Hi Alexandre,

I don't think that CMake is able to handle this. I searched for a
solution to a similar problem involving the use of the --start-group and
--end-group option for ld on Linux. You might be able to define custom
rules for this, but then you are definitely on platform-dependent
ground. Probably this would be something for a feature request.
If you find a solution to this, please let me know.

Best Regards

Martin

Alexandre Feblot wrote:
>
> Hi again,
>
> Would anybody have a solution for this?
>
> Thanks
>
> Alexandre
>
> 
>
> *Sent:* Monday, 30 March 2009 17:31
>
> Hi,
>
>  
>
> I import some libs like this:
>
>  
>
> add_library(${name} ${type} IMPORTED)
>
> set_target_properties(${name} PROPERTIES
>
> IMPORTED_LINK_INTERFACE_LIBRARIES "${other_imported_libs}"
>
> IMPORTED_LOCATION "${file}"
>
> )
>
>  
>
> At the end, I link an executable which gets all required libs thanks
> to the imported interface property.
>
>  
>
> Now, I need one of these imported libs to be surrouned like this: -z
> allextract ${the_lib} -z defaultextract
>
>  
>
> I find no working way to add these flags in the
> IMPORTED_LINK_INTERFACE_LIBRARIES properties to get them properly at
> link time. What solution do I have?
>
>  
>
>  
>
> Thanks
>
>
> This email was sent to you by Thomson Reuters, the global news and
> information company.
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be the
> views of Thomson Reuters. 



Virus checked by G DATA AntiVirus
Version: AVF 19.323 from 30.03.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Interpretation of RUNTIME_OUTPUT_DIRECTORY in VisualStudio

[Martin Apel]

Hi Michael,

thanks a lot, this solves the problem.

Regards,

Martin

Michael Jackson wrote:
> try the following:
> ADD_CUSTOM_TARGET(QtLibs
>  COMMAND ${CMAKE_COMMAND} -E
> copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/libQtCore.so.4
> ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}...)
>
>
>
> • CMAKE_CFG_INTDIR: Build time configuration directory for project.
> This is a variable that is used to provide developers access to the
> intermediate directory used by Visual Studio IDE projects. For
> example, if building Debug all executables and libraries end up in a
> Debug directory. On UNIX systems this variable is set to ".". However,
> with Visual Studio this variable is set to $(IntDir). $(IntDir) is
> expanded by the IDE only. So this variable should only be used in
> custom commands that will be run during the build process. This
> variable should not be used directly in a CMake command. CMake has no
> way of knowing if Debug or Release will be picked by the IDE for a
> build type. If a program needs to know the directory it was built in,
> it can use CMAKE_INTDIR. CMAKE_INTDIR is a C/C++ preprocessor macro
> that is defined on the command line of the compiler. If it has a
> value, it will be the intermediate directory used to build the file.
> This way an executable or a library can find files that are located in
> the build directory.
>
>
>
>
>
> _
> Mike Jackson  mike.jack...@bluequartz.net
> BlueQuartz Softwarewww.bluequartz.net
> Principal Software Engineer  Dayton, Ohio
>
>
>
> On Mar 17, 2009, at 8:40 AM, Martin Apel wrote:
>
>   
>> Hi all,
>>
>> I am trying to write CMake rules to copy shared libraries / DLLs to
>> the
>> runtime directory (not "installing"), right besides the binaries
>> generated by my project. In order to do this, I have rules like the
>> following:
>> ADD_CUSTOM_TARGET(QtLibs
>> COMMAND ${CMAKE_COMMAND}
>> -E
>> copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/libQtCore.so.4
>> ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}...)
>>
>> This works fine on Linux and Windows using the NMake generator.
>> However,
>> when using VisualStudio 8 under Windows, these libraries end up in the
>> directory, where CMAKE_RUNTIME_OUTPUT_DIRECTORY points to, whereas the
>> generated binaries are put into ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/
>> debug
>> or /release.
>>
>> Is the interpretation of what the RUNTIME_OUTPUT_DIRECTORY property or
>> the CMAKE_RUNTIME_OUTPUT_DIRECTORY means different for the Visual
>> Studio
>> generators? Do I have to put something like
>> IF (MSVC80)
>>  ...
>> ELSE(MSVC80)
>>  ...
>> ENDIF(MSVC80)
>>
>> into my CMakeLists.txt? Or is there a better solution?
>>
>> Best Regards,
>>
>> Martin
>>
>>
>>
>> 
>> Virus checked by G DATA AntiVirus
>> Version: AVF 19.302 from 16.03.2009
>>
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>> 
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
> .
>
>   


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  martin.a...@simpack.de

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  in...@simpack.de
Germany URL: http://www.simpack..com


Virus checked by G DATA AntiVirus
Version: AVF 19.302 from 16.03.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Interpretation of RUNTIME_OUTPUT_DIRECTORY in VisualStudio

[Martin Apel]

Hi all,

I am trying to write CMake rules to copy shared libraries / DLLs to the
runtime directory (not "installing"), right besides the binaries
generated by my project. In order to do this, I have rules like the
following:
ADD_CUSTOM_TARGET(QtLibs
 COMMAND ${CMAKE_COMMAND} -E
copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/libQtCore.so.4  
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}...)

This works fine on Linux and Windows using the NMake generator. However,
when using VisualStudio 8 under Windows, these libraries end up in the
directory, where CMAKE_RUNTIME_OUTPUT_DIRECTORY points to, whereas the
generated binaries are put into ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/debug
or /release.

Is the interpretation of what the RUNTIME_OUTPUT_DIRECTORY property or
the CMAKE_RUNTIME_OUTPUT_DIRECTORY means different for the Visual Studio
generators? Do I have to put something like
IF (MSVC80)
  ...
ELSE(MSVC80)
  ...
ENDIF(MSVC80)

into my CMakeLists.txt? Or is there a better solution?

Best Regards,

Martin




Virus checked by G DATA AntiVirus
Version: AVF 19.302 from 16.03.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CDash and submiting aditional information

[Martin Apel]

Hi Martin,

I am using Dart still, not CDash. But anyway, this is mainly a CTest
configuration issue. Here is what I do:
I have a CTest script which contains the following line:
SET (CTEST_NOTES_FILES "${CTEST_BINARY_DIRECTORY}/SVNVersionInfo.txt")

This file is generated to contain the Subversion revision number during
the build.

Hope this helps,

Martin (also :-)

Martin Santa María wrote:
> Hello everyone,
>  
> I have different nightly builds with different configurations for the
> same CDash Project. I would like to show descriptive information of
> these builds, for example, the options used to build each one. Is
> there a way to add some information to the submition in orther to
> archive this?
> Thanks all
>  
> Martin
>
> 
> con Windows Live Messenger comparte fotos mientras charlás. El doble
> de diversión: 



Virus checked by G DATA AntiVirus
Version: AVF 19.295 from 10.03.2009


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Installing shared libs with symlinks

[Martin Apel]

Philip Lowman wrote:
> On Fri, Dec 12, 2008 at 9:34 AM, Martin Apel  <mailto:martin.a...@simpack.de>> wrote:
>
> Philip Lowman wrote:
> > On Wed, Dec 10, 2008 at 4:04 AM, Martin Apel
> mailto:martin.a...@simpack.de>
> > <mailto:martin.a...@simpack.de <mailto:martin.a...@simpack.de>>>
> wrote:
> >
> > Hi there,
> >
> > I am trying to install the boost libraries my software needs
> into the
> > target installation directory as follows:
> >
> > Find_Package(Boost 1.34.1 COMPONENTS filesystem system signals
> > program_options REQUIRED)
> > FOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}
> > ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})
> >  INSTALL(PROGRAMS ${Lib} DESTINATION run/bin)
> > ENDFOREACH (Lib ${Boost_FILESYSTEM_LIBRARY}
> ${Boost_SYSTEM_LIBRARY}
> > ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})
> >
> > The variables returned from FindBoost contain symlinks to
> the real
> > libraries, e.g.
> >  libboost_system-gcc43-mt-1_35.so ->
> > libboost_system-gcc43-mt-1_35.so.1.35.0
> >
> > When installing these the files in the destination directory are
> > symlinks again, which is not what I want. I tried using
> >GET_FILENAME_COMPONENT(LibWithoutSymLink ${Lib} ABSOLUTE)
> > in the above loop, but this does not help, the returned path
> still
> > does
> > not contain the resolved name. This looks to me like a bug
> in the
> > implementation
> > of GET_FILENAME_COMPONENT. Is there any recommended way to
> install
> > referenced libraries including resolving any symlinks?
> >
> >
> > You could file a feature request to have that implemented.
>  Ultimately
> > though that won't be portable because on Windows it would
> resolve to a
> > ".lib" when you would want a ".dll".  And you probably want
> something
> > that works now for this.
> >
> >
> > Boost_INCLUDE_DIR in conjuction with FILE(GLOB...) and INSTALL()
> would
> > probably work much better for you.  Perhaps something like this?
> >
> > FILE(GLOB my_boost_system_libs
> > ${Boost_INCLUDE_DIR}/lib/libboost_system*.so)
> > IF(my_boost_system_libs)
> >  INSTALL(FILES ${my_boost_system_libs} DESTINATION lib)
> > ENDIF()
> >
> > Obviously you would need two GLOB's for this to be portable to
> WIN32.
> Hi Philip,
>
> I tried to avoid this, because the naming scheme for Boost
> libraries is
> complicated (compiler version, threading). Therefore I used the
> variables provided by FindBoost to get the names. Anyway I would have
> expected GET_FILENAME_COMPONENT to return the referenced file,
> which it
> doesn't. I'm still not sure, if this is a bug or expected behaviour?
>
>
> This looks like a missing feature request and not a bug.  I would
> request an option be added to GET_FILENAME_COMPONENT that follows
> symbolic links recursively back to their source (CANONICALIZE
> perhaps?).  In the meantime you can use the "readlink" program to do
> this for you.
Hi Philip,

to me it looks more like a bug, because the documentation for
GET_FILENAME_COMPONENT states, that for ABSOLUTE the file name is
returned without symlinks.
Anyway at least under Unix I could use readlink, but then I will have to
do platform-dependant stuff here, which I tried to avoid.

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.219 from 12.01.2009


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran module enclosed in #ifdef

[Martin Apel]

Michael Wild wrote:
> On 9. Jan, 2009, at 10:26, Martin Apel wrote:
>
>   
>> Michael Wild wrote:
>> 
>>> On 9. Jan, 2009, at 9:27, Martin Apel wrote:
>>>
>>>
>>>   
>>>> Hi all,
>>>>
>>>> I am experiencing a problem with one Fortran source file
>>>> containing a
>>>> module definition. Unfortunately the whole source file is enclosed
>>>> in
>>>> '#ifdef WINDOWS'. On Linux this causes the build process to fail,
>>>> because cmake wants to copy a generated .mod file, which does not
>>>> exist.
>>>> The file containing the module has the suffix ".f". When changing
>>>> the
>>>> suffix to ".F", everything works fine.
>>>> CMake probably thinks, the file need not be preprocessed before
>>>> scanning, if it has the suffix ".f". Is there any way to tell CMake,
>>>> that files with the suffix ".f" have to be preprocessed before
>>>> dependency scanning?
>>>>
>>>> Regards,
>>>>
>>>> Martin
>>>>
>>>>
>>>> 
>>> Hi
>>>
>>> I think it is fairly non-standard to have a .f file preprocessed. All
>>> Fortran compilers I'm acquainted with only preprocess a file if it
>>> has
>>> a .F extension (unless forced, of course).
>>>
>>> But since it is the whole file, can't you just exclude it in the
>>> CMake
>>> code?
>>>
>>> set( SRCS foo.f bar.f )
>>> if(WIN32)
>>>   list( APPEND SRCS winspecific.f )
>>> endif(WIN32)
>>>
>>> add_executable( super_cow ${SRCS} )
>>>
>>>   
>> You are right, that this is uncommon. But I'm trying to replace an
>> existing "build system" for some thousands of files, which
>> preprocesses
>> all Fortran files, even those with ".f" suffix. Unfortunately this is
>> something I can't change.
>> I could use the approach you suggest, but I'd like a more general
>> solution, because I cannot be sure, that this is the only file, where
>> preprocessing makes a difference. There might
>> be other files containing a USE directive enclosed in ifdefs.
>>
>> Regards,
>>
>> Martin
>>
>> 
>
> I just constructed a small test case, and it works for me (using
> CMake-2.6 and gfortran). See below.
>
> Michael
>
> test.f90:
> =
>
> program test
> #ifdef MORE
>use test_module
> #endif
>implicit none
>
>print *, "This is a test"
>
> #ifdef MORE
>call hello()
> #endif
>
> end program test
>
>
> modules/test_module.f90
> ===
>
> #ifdef MORE
> module test_module
>implicit none
>contains
>subroutine hello()
>  implicit none
>  print *,"Hello World"
>end subroutine
> end module test_module
> #endif
>
>
> CMakeLists.txt
> ==
>
> project( test Fortran )
>
> cmake_minimum_required( VERSION 2.6 )
>
> option( DEFINE_MORE "If set to ON, -DMORE will be defined" OFF )
> # force gfortran to preprocess the input files
> # change this to "-fpp" for ifort (that's the ones i know...)
> set( FORTRAN_PREPROCESS_FLAG "-x f95-cpp-input" CACHE STRING
>"Flags to force the Fortran compiler to preprocess the source
> files.")
>
> if( DEFINE_MORE )
>add_definitions( -DMORE )
> endif( DEFINE_MORE )
>
> add_executable( test test.f90 modules/test_module.f90 )
>
> set_target_properties( test PROPERTIES COMPILE_FLAGS $
> {FORTRAN_PREPROCESS_FLAG} ))
>
> .
>
>   
Good idea, but unfortunately this doesn't help in my case. The fact,
that I have two nested '#if defined' statements, seems to make a
difference. I have searched the CMake sources a bit. I found a comment
in cmDependsFortran.cxx as follows:
  /* Note: The current parser is _not_ able to get statements like
   *   #if 0
   *   #if 1
   *   #if MYSMBOL
   *   #if defined(MYSYMBOL)
   *   #if defined(MYSYMBOL) && ...
   * right.  The same for #elif.  Thus in
   *   #if SYMBOL_1
   * ..
   *   #elif SYMBOL_2
   * ...
   * ...
   *   #elif SYMBOL_N
   * ..
   *   #else
   * ..
   *   #endif
   * _all_ N+1 branches are considered.  If you got something like this
   *   #if defined(MYSYMBOL)
   *   #if !defined(MYSYMBOL)
   * use
   *   #ifdef MYSYMBOL
   *   #ifndef MYSYMBOL
   * instead.
   */

I have exactly the first case with two nested '#if defined' directives.
Changing these to '#ifdef' solved the problem for me. Not nice,
but this works around CMake's problem.

Thanks for your help,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.215 from 08.01.2009


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran module enclosed in #ifdef

[Martin Apel]

Arjen Markus wrote:
>> You are right, that this is uncommon. But I'm trying to replace an
>> existing "build system" for some thousands of files, which preprocesses
>> all Fortran files, even those with ".f" suffix. Unfortunately this is
>> something I can't change.
>> I could use the approach you suggest, but I'd like a more general
>> solution, because I cannot be sure, that this is the only file, where
>> preprocessing makes a difference. There might
>> be other files containing a USE directive enclosed in ifdefs.
>>
>> 
>
> Most compilers seem to have a switch to turn preprocessing on,
> no matter what the extension is. While that is not very portable
> (but then, .F is not either!), it will get you going.
>   
Yes, I know. But my problem is not with the compiler itself, but with
CMake. It seems to assume, that during scanning of dependency and module
information,
files with a suffix of ".f" don't have to be preprocessed, whereas files
with ".F" are preprocessed. I am searching for a way to tell CMake to
perform preprocessing during dependency scanning for files with ".f".

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.215 from 08.01.2009


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with Fortran module enclosed in #ifdef

[Martin Apel]

Michael Wild wrote:
> On 9. Jan, 2009, at 9:27, Martin Apel wrote:
>
>   
>> Hi all,
>>
>> I am experiencing a problem with one Fortran source file containing a
>> module definition. Unfortunately the whole source file is enclosed in
>> '#ifdef WINDOWS'. On Linux this causes the build process to fail,
>> because cmake wants to copy a generated .mod file, which does not
>> exist.
>> The file containing the module has the suffix ".f". When changing the
>> suffix to ".F", everything works fine.
>> CMake probably thinks, the file need not be preprocessed before
>> scanning, if it has the suffix ".f". Is there any way to tell CMake,
>> that files with the suffix ".f" have to be preprocessed before
>> dependency scanning?
>>
>> Regards,
>>
>> Martin
>>
>> 
>
> Hi
>
> I think it is fairly non-standard to have a .f file preprocessed. All
> Fortran compilers I'm acquainted with only preprocess a file if it has
> a .F extension (unless forced, of course).
>
> But since it is the whole file, can't you just exclude it in the CMake
> code?
>
> set( SRCS foo.f bar.f )
> if(WIN32)
>list( APPEND SRCS winspecific.f )
> endif(WIN32)
>
> add_executable( super_cow ${SRCS} )
>   
You are right, that this is uncommon. But I'm trying to replace an
existing "build system" for some thousands of files, which preprocesses
all Fortran files, even those with ".f" suffix. Unfortunately this is
something I can't change.
I could use the approach you suggest, but I'd like a more general
solution, because I cannot be sure, that this is the only file, where
preprocessing makes a difference. There might
be other files containing a USE directive enclosed in ifdefs.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.215 from 08.01.2009


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with Fortran module enclosed in #ifdef

[Martin Apel]

Hi all,

I am experiencing a problem with one Fortran source file containing a
module definition. Unfortunately the whole source file is enclosed in
'#ifdef WINDOWS'. On Linux this causes the build process to fail,
because cmake wants to copy a generated .mod file, which does not exist.
The file containing the module has the suffix ".f". When changing the
suffix to ".F", everything works fine.
CMake probably thinks, the file need not be preprocessed before
scanning, if it has the suffix ".f". Is there any way to tell CMake,
that files with the suffix ".f" have to be preprocessed before
dependency scanning?

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.215 from 08.01.2009


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Passing -j (or other make flags) to make?

[Martin Apel]

Tyler Roscoe wrote:
> Is there a way to set flags for make from my CMakeLists.txt?
>
> Specifically, I have a cluster of build machines and I would like each
> of them to use a specific -j flag. (I would set the -j flag in a
> "global" cmake file where I set up things like project-wide -D flags and
> third-party library locations.)
>
> -j is a make option, not a compiler option, so I can't use
> ADD_DEFINITIONS or CMAKE_CXX_FLAGS.
>
> I couldn't find anything with google. This old thread talks about
> $(MAKEFLAGS) but setting that variable doesn't seem to help me:
>
> http://www.cmake.org/pipermail/cmake/2003-October/004398.html
>
> Is this possible? Or do I need to make a wrapper script to set up extra
> options for make?
>   
This is something not related to cmake. However you can set the
environment variable MAKEFLAGS in your .cshrc or whatever init file you
have for your shell.
You can do this depending on the system and get the behaviour you need.
I have been doing this since I have a quad core machine at work :-)

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.191 from 17.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] add_custom_target always runs?

[Martin Apel]

Tyler Roscoe wrote:
> On Tue, Dec 16, 2008 at 09:44:38PM +0100, Eric NOULARD wrote:
>   
>>> Ok, so is it simply impossible to do delta builds if my build process
>>> needs add_custom_command/add_custom_target invocations? Is there some
>>> better way to have CMake create the headers for me? Does this behavior
>>> of add_custom_target only occur when I add a new target dependent on
>>> ALL?
>>>   
>> Why do you add "ALL" in your case?
>>
>> Won't generateheader be called when needed when you remove the ALL
>> argument to add_custom_target?
>>
>> Note that another way to go is completely remove the add_custom_target
>> and add the generated header to the concerned add_executable /
>> add_library command.
>>
>> then you have to:
>>
>> set_source_files_properties(results/header.h PROPERTIES GENERATED true)
>>  in order to avoid to make add_library/add_executable shout at you
>> about missing files.
>>
>> Then when the concerned libraries and/or executable are built
>> CMake should automatically run your add_custom_command since it
>> advertise it has the missing "results/header.h" as output.
>> 
>
> I presented a simplified version of my problem. In reality, I have a
> cmake project that takes a bunch of headers, mangles them with scripts,
> and then collects them in a directory so I can have a single
> INCLUDE_DIR.
>
> I would like to handle all these headers by themselves rather than
> having DEPENDS references to them all over the source tree. The way I
> have it now, BigLibrary1... BigLibraryN INCLUDE() Headers/CMakeLists.txt
> so that all the headers can be "built" before trying to build one of the
> BigLibraries.
>
> Am I thinking about this the wrong way? I find that the way I think
> about build problems is often quite different from how CMake thinks
> about those same problems.
>   
I had a similar problem some time ago. I worked around it by first
generating the header files into ${CMAKE_CURRENT_BINARY_DIR} and then
execute 'cmake -E
copy_if_different' to their target location. This way dependent files
will only be rebuilt, if the header has actually changed.

Hope this helps,

Martin





Virus checked by G DATA AntiVirus
Version: AVF 19.189 from 16.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Installing shared libs with symlinks

[Martin Apel]

Hi there,

I am trying to install the boost libraries my software needs into the
target installation directory as follows:

Find_Package(Boost 1.34.1 COMPONENTS filesystem system signals
program_options REQUIRED)
FOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}
${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})
  INSTALL(PROGRAMS ${Lib} DESTINATION run/bin)
ENDFOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}
${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})

The variables returned from FindBoost contain symlinks to the real
libraries, e.g.
  libboost_system-gcc43-mt-1_35.so ->
libboost_system-gcc43-mt-1_35.so.1.35.0

When installing these the files in the destination directory are
symlinks again, which is not what I want. I tried using
GET_FILENAME_COMPONENT(LibWithoutSymLink ${Lib} ABSOLUTE)
in the above loop, but this does not help, the returned path still does
not contain the resolved name. This looks to me like a bug in the
implementation
of GET_FILENAME_COMPONENT. Is there any recommended way to install
referenced libraries including resolving any symlinks?

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.180 from 09.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] per-configuration defines

[Martin Apel]

Michele Bosi wrote:
> Hi all,
> is there a way to issue extra preprocessor defines on a
> build-configuration basis, that is: I would like to add some
> preprocessor defines to my release builds and others to my debug
> builds. Basically I would need something like:
>
> add_definitions_release(-DDEFINE1 -DDEFINE2)
> add_definitions_debug(-DDEFINE3 -DDEFINE4)
>
> I know that I could also do it using the target properties like:
> SET_TARGET_PROPERTIES(target PROPERTIES
>  COMPILE_DEFINITIONS_ "-DDEFINEn") but since I
> have several targets spread all over the world it would be nice to be
> able to add such defines once and for all :)
>
> Regards,
> Michele
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
>   
The easiest way is to simply add these defines to CMAKE_C_FLAGS_DEBUG,
CMAKE_C_FLAGS_RELEASE etc.

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.180 from 09.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Win: Dependency for def file missing

[Martin Apel]

Bill Hoffman wrote:
> Martin Apel wrote:
>> Hi all,
>>
>> I am generating a DLL under Windows using a def file. The def file
>> itself is generated. It seems that CMake (2.6.3rc5) does not generate a
>> dependency between the generated def file and the DLL. When I change the
>> input, from which the def file is generated, the def file is rebuilt,
>> but not the DLL itself. The code looks as follows:
>>
>>   SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
>>   ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
>>  COMMAND ${PERL_EXECUTABLE}
>> ${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
>>  --export-file=${DefFile} --so-name=FortranInterface
>> 
>> ${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
>>  DEPENDS
>> ${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
>>  )
>>
>>   ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
>>   TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
>>   SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
>> LINK_INTERFACE_LIBRARIES "")
>>
>>   SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)
>>
>> To me this looks like a bug in CMake. Can somebody confirm, that this is
>> a bug or am I doing something wrong?
>>
> What version of VS are you using?   Also, nmake or VS IDE?
>
Hi Bill and all the rest,

sorry, I forgot to state this: VS version is 2005 and I am using nmake.

Best Regards,

Martin


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com


Virus checked by G DATA AntiVirus
Version: AVF 19.178 from 08.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Win: Dependency for def file missing

[Martin Apel]

Hi all,

I am generating a DLL under Windows using a def file. The def file
itself is generated. It seems that CMake (2.6.3rc5) does not generate a
dependency between the generated def file and the DLL. When I change the
input, from which the def file is generated, the def file is rebuilt,
but not the DLL itself. The code looks as follows:

  SET(DefFile ${CMAKE_CURRENT_BINARY_DIR}/FortranInterface.def)
  ADD_CUSTOM_COMMAND(OUTPUT ${DefFile}
 COMMAND ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/create_dll_exports_file.pl
 --export-file=${DefFile} --so-name=FortranInterface
 ${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
 DEPENDS
${CMAKE_CURRENT_SOURCE_DIR}/FortranInterfaceExport.txt
 )

  ADD_LIBRARY(FortranInterface SHARED ${DefFile} ${FortranSrc})
  TARGET_LINK_LIBRARIES(FortranInterface ${MY_LIBS})
  SET_TARGET_PROPERTIES(FortranInterface PROPERTIES
LINK_INTERFACE_LIBRARIES "")

  SET_SOURCE_FILES_PROPERTIES(${DefFile} PROPERTIES GENERATED 1)

To me this looks like a bug in CMake. Can somebody confirm, that this is
a bug or am I doing something wrong?

Regards,

Martin




Virus checked by G DATA AntiVirus
Version: AVF 19.178 from 08.12.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] making Nightly builds easier to setup

[Martin Apel]

Alexander Neundorf wrote:
> On Monday 10 November 2008, Martin Apel wrote:
> ...
>   
>> I recently played around with nightly builds as well. I used to have a
>> setup for experimental builds, but never could get the svn checkout to
>> run. With the approach described above, I was finally able
>> to run checkout from svn from within ctest. Unfortunately it seems that
>> some variables are not used anymore with this approach of generating
>> builds. I found that CTEST_INITIAL_CACHE 
>> 
>
> I plan to do something about this.
>
>   
>> as well as CTEST_ENVIRONMENT seem
>> 
>
> This one probably too.
>
> Which other problems do you have in detail ?
>   
Hi Alex,

thanks a lot for your initiative to improve the situation with CTest.
For the CTEST_INITIAL_CACHE issue I used 'FILE WRITE' as recommended by
David, which works fine now.
There are three remaining problems with ctest:
1. Memory checking using valgrind
2. Coverage testing using gcov
3. Setting the test timeout correctly
4. Excluding certain tests during memchecking

My old setup looked like this:

SET (CTEST_INITIAL_CACHE "
MAKECOMMAND:STRING=make -i -j3 world
DART_TESTING_TIMEOUT:STRING=3600
CMAKE_CXX_FLAGS_DEBUG:STRING=-g -fprofile-arcs -ftest-coverage
CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING=-g -fprofile-arcs -ftest-coverage
CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=-g -fprofile-arcs -ftest-coverage
COVERAGE_COMMAND:STRING=gcov-4.2
")

SET (CTEST_CMAKE_COMMAND  "cmake -DCMAKE_BUILD_TYPE=Debug")
SET (CTEST_COMMAND  
 "ctest -D Experimental"
 "ctest -D ExperimentalMemCheck -E Compare"
 "ctest -D ExperimentalSubmit"
 )

For the new script I tried something along these lines:
SET (CTEST_MEMORYCHECK_COMMAND "valgrind")
SET (CTEST_MEMORYCHECK_COMMAND_OPTIONS "--tool=memcheck")
SET (CTEST_TESTING_TIMEOUT 3600)
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_build(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_test(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_memcheck(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_coverage(BUILD "${CTEST_BINARY_DIRECTORY}" )
ctest_submit()

1. Memory checking: This didn't work, CTest complained, that it could
not find the memory checker. From the source code I had the impression,
that valgrind should work
automatically if found. The relevant output from ctest is the following:
SetCTestConfigurationFromCMakeVariable:MemoryCheckCommand:CTEST_MEMORYCHECK_COMMANDSetCTestConfiguration:MemoryCheckCommand:valgrind
SetCTestConfigurationFromCMakeVariable:MemoryCheckCommandOptions:CTEST_MEMORYCHECK_COMMAND_OPTIONSSetCTestConfiguration:MemoryCheckCommandOptions:--tool=memcheck
SetCTestConfiguration:BuildDirectory:/tmp/new_arch_nightly_build/obj/dbg
SetCTestConfiguration:SourceDirectory:/tmp/new_arch_nightly_build
Memory check project /tmp/new_arch_nightly_build/obj/dbg
Memory checker (MemoryCheckCommand) not set, or cannot find the
specified program.

2. Also the coverage command did not work, although the compile flags
have been set correctly (with -fprofile-arcs etc.). The .gcda files are
produced, which proves, that the
binaries are build correctly, but it seems that gcov is not called.
I haven't found a possibility to explicitly set the command name of the
gcov binary, which is gcov-4.2 in my case.
The relevant output here is this:

 Add coverage exclude regular expressions.
SetCTestConfiguration:BuildDirectory:/tmp/new_arch_nightly_build/obj/dbg
SetCTestConfiguration:SourceDirectory:/tmp/new_arch_nightly_build
Performing coverage
 COVFILE environment variable not found, not running  bullseye
   Processing coverage (each . represents one file):
."" -l -o
"/tmp/new_arch_nightly_build/obj/dbg/project/CMakeFiles/Project.dir"
"/tmp/new_arch_nightly_build/obj/dbg/project/CMakeFiles/Project.dir/ProjectElement.cpp.gcda"
No such file or directory
. repeated for lots of source files
Cannot find any coverage files. Ignoring Coverage request.

3. I have one test, which takes longer than the default 10 minutes per
test, which has been killed. So I assume that CTEST_TESTING_TIMEOUT has
been ignored
or is not the right variable to set.
4. I have searched for a possibility to exclude certain tests from
memory checking from within the script, but haven't found any.

So this is it. If you could help me to get this running, I would be very
grateful. Currently I don't have the time to search through the source
code to find these things out myself :-)

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.142 from 12.11.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] making Nightly builds easier to setup

[Martin Apel]

Hi all,

writing the CMakeCache.txt in advance works fine, thanks. Anyway, I
haven't been able to get some things to work which work for my
experimental setup,
which uses old-style CTest scripts. Memory checking and coverage tests
do not work anymore. I searched through the sources of CMake a bit, but
I could not get
it to work yet. As I currently do not have the time to fiddle around
with all these undocumented changes, I will stay with my old setup for
the time being.
When the documentation of this new-style scripting improves, I will give
it another try.

Regards,

Martin

David Cole wrote:
> The variable CTEST_INITIAL_CACHE is ignored in new-style
> (CTEST_BUILD() command based) ctest scripts.
>
> Instead, you should use:
>
> FILE(WRITE "${CTEST_BINARY_DIRECTORY}/CMakeCache.txt" "
> MAKECOMMAND:STRING=nmake -i
> CMAKE_MAKE_PROGRAM:FILEPATH=nmake
> CMAKE_GENERATOR:INTERNAL=NMake Makefiles
> BUILDNAME:STRING=Win32-nmake71
> SITE:STRING=VOGON.kitware
> CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
> ")
>
> (But only on a clean build, after calling
> CTEST_EMPTY_BINARY_DIRECTORY("${CTEST_BINARY_DIRECTORY}"), or perhaps
> only if the CMakeCache.txt does not exist in the first place...)
>
> HTH,
> David
>
>
> On Mon, Nov 10, 2008 at 5:33 AM, Martin Apel <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Eric Noulard wrote:
> > 2008/11/9 Alexander Neundorf <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>:
> > [...]
> >
> >
> >> commands can be executed.
> >>
> >> IMO this can make setting up Nightly builds much easier.
> >>
> >
> > Looks interesting, I didn't ever thought ctest scripting was
> done for that.
> > I did shell scripts for that and was wondering how to do it on
> Windows :-)
> >
> > Now I know.
> >
> >
> >> What do you think ?
> >> One thing which is still missing is a way how to get variables
> predefined into
> >> the cmake-configure run during ctest_configure().
> >> Does this have to be done by writing an initial CMakeCache.txt ?
> >>
> >
> > This seems possible using "CTEST_INITIAL_CACHE"
> > as shown here:
> > http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
> <http://www.vtk.org/Wiki/CMake_Script-disableding_Of_CTest>
> >
> > # this is the initial cache to use for the binary tree, be
> careful to escape
> > # any quotes inside of this string if you use it
> > SET (CTEST_INITIAL_CACHE "
> > MAKECOMMAND:STRING=nmake -i
> > CMAKE_MAKE_PROGRAM:FILEPATH=nmake
> > CMAKE_GENERATOR:INTERNAL=NMake Makefiles
> > BUILDNAME:STRING=Win32-nmake71
> > SITE:STRING=VOGON.kitware
> > CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
> > ")
> >
> I recently played around with nightly builds as well. I used to have a
> setup for experimental builds, but never could get the svn checkout to
> run. With the approach described above, I was finally able
> to run checkout from svn from within ctest. Unfortunately it seems
> that
> some variables are not used anymore with this approach of
> generating builds.
> I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem
> to be
> ignored, when using CTEST_BUILD etc. For the environment variables I
> could get it to work by setting
> the environment variables explicitly, e.g. 'SET (ENV{CC} "gcc-4.2")'.
> That means that the approach proposed above does not work, at
> least not
> for me.
>
> After all I'm somewhat confused about this new approach ignoring
> some of
> the variables. Maybe someone with a deeper knowledge of ctest could
> explain, what's going on here.
>
> Regards,
>
> Martin
> 
> Virus checked by G DATA AntiVirus
> Version: AVF 19.138 from 09.11.2008
>
>
> ___
> CMake mailing list
> CMake@cmake.org <mailto:CMake@cmake.org>
> http://www.cmake.org/mailman/listinfo/cmake
>
>



Virus checked by G DATA AntiVirus
Version: AVF 19.140 from 10.11.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] making Nightly builds easier to setup

[Martin Apel]

Eric Noulard wrote:
> 2008/11/9 Alexander Neundorf <[EMAIL PROTECTED]>:
> [...]
>
>   
>> commands can be executed.
>>
>> IMO this can make setting up Nightly builds much easier.
>> 
>
> Looks interesting, I didn't ever thought ctest scripting was done for that.
> I did shell scripts for that and was wondering how to do it on Windows :-)
>
> Now I know.
>
>   
>> What do you think ?
>> One thing which is still missing is a way how to get variables predefined 
>> into
>> the cmake-configure run during ctest_configure().
>> Does this have to be done by writing an initial CMakeCache.txt ?
>> 
>
> This seems possible using "CTEST_INITIAL_CACHE"
> as shown here:
> http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
>
> # this is the initial cache to use for the binary tree, be careful to escape
> # any quotes inside of this string if you use it
> SET (CTEST_INITIAL_CACHE "
> MAKECOMMAND:STRING=nmake -i
> CMAKE_MAKE_PROGRAM:FILEPATH=nmake
> CMAKE_GENERATOR:INTERNAL=NMake Makefiles
> BUILDNAME:STRING=Win32-nmake71
> SITE:STRING=VOGON.kitware
> CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
> ")
>   
I recently played around with nightly builds as well. I used to have a
setup for experimental builds, but never could get the svn checkout to
run. With the approach described above, I was finally able
to run checkout from svn from within ctest. Unfortunately it seems that
some variables are not used anymore with this approach of generating builds.
I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem to be
ignored, when using CTEST_BUILD etc. For the environment variables I
could get it to work by setting
the environment variables explicitly, e.g. 'SET (ENV{CC} "gcc-4.2")'.
That means that the approach proposed above does not work, at least not
for me.

After all I'm somewhat confused about this new approach ignoring some of
the variables. Maybe someone with a deeper knowledge of ctest could
explain, what's going on here.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.138 from 09.11.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FindBoost and gcc 4.3.2

[Martin Apel]

Olivier Tournaire wrote:
> Hi all,
>
> I use boost in one of my project. However, cmake (2.6.2) does not seem
> to be able to find the libs. With the previous version of gcc (4.2.4),
> I did not have any problem. Here is what is in my CMakeLists.txt :
>
> # Find BOOST
> # SET( BOOST_LIBRARYDIR /usr/local/lib )
> SET(Boost_USE_MULTITHREAD ON)
> FIND_PACKAGE( Boost 1.36.0 COMPONENTS filesystem system thread )
> IF( Boost_FOUND )
> ELSE( Boost_FOUND )
> MESSAGE(FATAL_ERROR "Boost not found ! Please set Boost path ...")
> ENDIF( Boost_FOUND )
>
> My first idea was to recompile boost with the new gcc version.
> However, I still have the problem. For info, here are the filesystem
> libs available in /usr/local/lib :
Hi Olivier,

I also had some trouble with FindBoost in the past.
Please check the output of 'gcc --version'. There used to be a bug
(7097), which misinterpreted the compiler version here. The bug is
marker as resolved
and it works for me, but if the version information of your compiler is
somehow strange, the problem might lie here. The output of my gcc 4.3.0
is "gcc-4.3 (GCC) 4.3.0", which works with CMake 2.6.2.

If this is not the problem, you will have to enter some MESSAGE lines
into FindBoost.cmake to find out what's going wrong.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.113 from 24.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] "Command line too long" under Windows

[Martin Apel]

Brad King wrote:
> Brad King wrote:
>   
>> CMake once just listed the object files on the command line in the
>> makefile, but users hit command line length limits with several hundred
>> object files.  We solved the problem by listing the objects in a
>> response file.  Now it looks like you've hit another limit of the MSVC
>> tools.  The fix to CMake will have to be to create *multiple* response
>> files each of which is under 131071 characters.  Please submit a request
>> 
>
> Nevermind, I've already fixed it.  Please try building from CVS HEAD to
> make sure it fixes your problem.
>   
Hi Bill,

thanks for your quick fix. I tried it out with both generators and it
works fine!
Will this fix make it into 2.6.3?

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVF 19.101 from 15.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] "Command line too long" under Windows

[Martin Apel]

Hi all,

I am currently in the process of trying to convert the build system of
our software to CMake.
Unfortunately there is one static library consisting of lots of objects
(about 5700), which has lots of cyclic references, so I cannot easily
split it up.
I can generate this large library on Linux without problems. When trying
to do the same under Windows, the build fails, because the link line is too
long:
  "CMakeFiles/spck.dir/objects.rsp : fatal error LNK1170: line in
command file contains 131071 or more characters"

An inspection of the file shows a single line with about 300.000
characters. Is there any way to work around this problem besides
splitting up
the library? The CMake version I am using is 2.6.2 and I have tried with
both the Visual Studio 8 generator (nmake) and the Unix makefile generator,
but the problem shows up with both approaches.

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVB 19.64 from 15.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Output of ADD_CUSTOM_COMMAND generated multiple times

[Martin Apel]

Brad King wrote:
> We've built huge projects with thousands of custom build rules while
> still only having a few custom targets.  Your original example can be
> written like this:
>
> ADD_CUSTOM_COMMAND(
>   OUTPUT ${CMAKE_BINARY_DIR}/a
>   COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/a
>   )
> ADD_CUSTOM_COMMAND(
>   OUTPUT ${CMAKE_BINARY_DIR}/b
>   COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
>   DEPENDS ${CMAKE_BINARY_DIR}/a
>   )
> ADD_CUSTOM_COMMAND(
>   OUTPUT ${CMAKE_BINARY_DIR}/c
>   COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
>   DEPENDS ${CMAKE_BINARY_DIR}/a
>   )
> ADD_CUSTOM_TARGET(world
>   DEPENDS ${CMAKE_BINARY_DIR}/b ${CMAKE_BINARY_DIR}/c
>   )
>
> Now the 'world' target contains all the rules and will build 'a' first,
> then 'b' and 'c' in parallel.
>
>   
Thanks a lot, Brad. This approach improves my build output very much!
>> I think CMake should be smart enough to handle this without the extra
>> targets, at least as long as all of them are in
>> the same directory. That is what the "generated" attribute of a source
>> file is about, isn't it.
>> But for now, I will modify my CMakeLists.txt to contain the extra targets.
>> 
>
> There is a feature request here:
>
> http://www.cmake.org/Bug/view.php?id=6285
>
> However, the solution I have in mind for it will still not handle your
> case.  You're basically telling two different targets how to build a
> file, and not adding any other dependencies to control the order.
>
> Each target gets built with its own make process.  It is at this stage
> that file-level dependencies are evaluated by the build system.  A
> higher-level make process considers only inter-target dependencies with
> symbolic (phony) targets.
>   
It would be nice, if CMake could compute these dependencies
automatically, but there have to be
some features left for CMake 3.0 :-)

Martin


Virus checked by G DATA AntiVirus
Version: AVB 19.56 from 08.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Output of ADD_CUSTOM_COMMAND generated multiple times

[Martin Apel]

Alan W. Irwin wrote:
> On 2008-10-07 16:09-0400 Brad King wrote:
>
>> Now targets b and c and build in parallel, but neither will build until
>> 'a' is generated.
>
> Thanks, Brad, for your further explanation and example.  My method
> (which I
> started to use as a result of misinterpreting something you said on this
> topic before) appears to work, but yours is certainly more logical and
> will
> most likely result in faster parallel builds (because of the
> serialization
> used by my method).  If your example isn't in the wiki, it should be.

The only unfortunate side effect of this approach of defining a separate
target for each custom command is that
I start drowning in the make output "Build target x", because I have
lots of these dependencies.
I think CMake should be smart enough to handle this without the extra
targets, at least as long as all of them are in
the same directory. That is what the "generated" attribute of a source
file is about, isn't it.
But for now, I will modify my CMakeLists.txt to contain the extra targets.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVB 19.56 from 08.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Output of ADD_CUSTOM_COMMAND generated multiple times

[Martin Apel]

Hi all,

I'm experiencing the following problem with ADD_CUSTOM_COMMAND:
The commands defined for it are executed multiple times, if multiple
targets depend on it and I run a parallel make afterwards.
An example makes this easier to understand:

PROJECT(Test)
cmake_minimum_required(VERSION 2.6)

ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/a
   COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/a)

ADD_CUSTOM_TARGET(b
  COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/b
  DEPENDS ${CMAKE_BINARY_DIR}/a)
ADD_CUSTOM_TARGET(c
  COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/c
  DEPENDS ${CMAKE_BINARY_DIR}/a)

ADD_CUSTOM_TARGET(world)
ADD_DEPENDENCIES(world b)
ADD_DEPENDENCIES(world c)


When running a "make -j2 world" afterwards, the following output appears:
[  0%] [  0%] Generating a
Generating a
[ 50%] [100%] Built target b
Built target c
[100%] Built target world

When doing a "make -j1 world", a is generated only once. From my
understanding a should only be generated once in the first case as well.
Am I misunderstanding anything or is this a bug in CMake? CMake version
is 2.6.2 on Linux.

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.91 from 06.10.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem with set_target_properties on mixed-source library

[Martin Apel]

Alan W. Irwin wrote:
> On 2008-09-29 16:00+0200 Martin Apel wrote:
>
>> Hi all,
>>
>> I have a library consisting of multiple sources from Fortran and C, e.g.
>> file1.f, file2.f, file3.c.
>> I want to generate this library in two different versions, where in one
>> of those versions the Fortran files are compiled with different options,
>> in my case with -ipo.
>> That means:
>>libv1.a   = file1.o file2.o file3.o   compiled without
>> ipo-options
>>libv2.a   = file1.o file2.o with ipo-option, file3.o without
>> ipo-option
>>
>> I tried to use set_target_properties on libv2 to set the ipo-flag, but
>> this also sets this option for the C files, which the compiler does not
>> understand.
>> I also cannot use set_source_properties, because the same source files
>> will be compiled with different options.
>>
>
>
Hi Alan,

> The scenario I am thinking about is the one where you set source
> properties
> with non-ipo flag, build your non-ipo library, then set the source
> properties _again_ using ipo flag, and build your ipo library. Setting
> a new
> compilation flag using set_source_properties should (in an ideal
> world) mean
> that the source gets recompiled, but that is just my opinion and the
> CMake
> developers may be up against practical constraints that don't allow
> this or
> they may have intended recompilation to take place whenever a compile
> flag
> is changed, but there may be a bug in the implementation for Fortran
> or in
> general.
I think this does not work. I have tried setting and resetting some
flags in the same CMakeLists.txt before
and CMake always uses the value of variables in effect, when the end of
file is reached.
>
> To further the discussion and be absolutely sure about the behaviour
> you are
> reporting, I suggest you make the simplest-possible self-contained
> example
> of the issue consisting of a CMakeLists.txt file and two "hello
> world1" and
> "hello-world2" source files where the first one (only) should have
> different
> compiler flags for two distinct libraries that you build. Also, to
> rule out
> a Fortran specific bug, the two different files should be C.  Then you
> should be able to show (using make VERBOSE=1) exactly what flags are used
> for each build and indeed whether the object is rebuilt (like I think it
> should be in an ideal world) because of the changed compile flags set
> with
> source properties.
The problem will not show up, if I only use C files. The problem is,
that you cannot distinguish
between Fortran flags and C flags when using
  SET_TARGET_PROPERTIES (v2 PROPERTIES COMPILE_FLAGS "-ipo")
Those flags will be applied to both C and Fortran sources, if the target
contains both.
>From my point of view this is not really a bug, but a missing feature.
If requested by
the CMake developers I can provide a small example.

> To actually work around your problem rather than boiling it down to a
> simplest case that would potentially convince the CMake developers
> there is
> a bug or misfeature here, you could simply copy your source files (with
> CMake so you only have to maintain one set of source files) and proceed
> independently for the two libraries with differently named source
> files when
> compiled with different flags.
I thought about this as well, but I would like to avoid it, because
there's quite a bunch
of files in different subdirectories to be handled. It's not impossible,
but at least very cumbersome.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVB 19.43 from 29.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with set_target_properties on mixed-source library

[Martin Apel]

Hi all,

I have a library consisting of multiple sources from Fortran and C, e.g.
file1.f, file2.f, file3.c.
I want to generate this library in two different versions, where in one
of those versions the Fortran files are compiled with different options,
in my case with -ipo.
That means:
libv1.a   = file1.o file2.o file3.o   compiled without
ipo-options
libv2.a   = file1.o file2.o with ipo-option, file3.o without ipo-option

I tried to use set_target_properties on libv2 to set the ipo-flag, but
this also sets this option for the C files, which the compiler does not
understand.
I also cannot use set_source_properties, because the same source files
will be compiled with different options.

How can I use CMake to generate both libraries with the correct flags?
Both libraries have to be generated for the same build configuration, so
I cannot make the distinction
with respect to build configurations.

Regards,

Martin

Virus checked by G DATA AntiVirus
Version: AVB 19.43 from 29.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Override of link flag for one specific shared library

[Martin Apel]

I resorted to turn off the flags for the complete directory. In this
case, this was possible, because they were only intended to speed up
C++-template instantiation. So for this one directory template
instantiation is handled in the slower way, but I can live with that.
However, I think there should be a way to override flags for a single
target. The easiest way from my point of view would be to adjust the
CMake-rules to contain the target-specific flags after the global flags,
not before.

Regards,

Martin

David Cole wrote:
> ADD_SUBDIRECTORY is the "right" thing to be using. SUBDIRS is
> deprecated, but they process things subtly differently, so I just
> wanted to rule out that you might be encountering a "SUBDIRS side
> effect"...
>
> You've ruled it out.
>
> Could you re-organize such that libraries with different flags are in
> different CMakeLists files?
>
>
> On Mon, Sep 8, 2008 at 3:02 AM, Martin Apel <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I am using ADD_SUBDIRECTORY. I did'nt know, that anything like SUBDIRS
> exists and haven't found anything in the documentation about it.
>
> Martin
>
>
> David Cole wrote:
> > Are you using SUBDIRS or ADD_SUBDIRECTORY in your project...?
> >
> >
> > On Thu, Sep 4, 2008 at 2:42 AM, Martin Apel
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> wrote:
> >
> > Unfortunately this does not work. It seems that CMake
> generates all
> > libraries defined in one CMakeLists.txt with the setting of
> > CMAKE_SHARED_LINKER_FLAGS at the end of the file.
> > This causes this setting to be applied to all libraries in the
> > CMakeLists.txt. As I have 4 libraries in this one
> CMakeLists.txt, this
> > doesn't help much.
> >
> > I tried to do something like the following:
> > SET (CMAKE_SHARED_LINKER_FLAGS "${ORIG_SHARED_LINKER_FLAGS}")
> > ADD_LIBRARY (FortranInterface ${OBJS})
> > SET (CMAKE_SHARED_LINKER_FLAGS
> "${MODIFIED_SHARED_LINKER_FLAGS}")
> > but the FortranInterface library gets built with
> > MODIFIED_SHARED_LINKER_FLAGS in effect.
> >
> > I would suggest to change the order of items in the build
> rules for a
> > future CMake release, such that it's possible to override
> general
> > flags
> > with a target specific property. Today the link
> > rules look as follows:
> > SET(CMAKE_CXX_CREATE_SHARED_LIBRARY " ...
> >   ")
> > >From my point of view it would be better to put LINK_FLAGS
> to the
> > end of
> > the list (not only for shared libraries, but in general).
> >
> > Regards,
> >
> > Martin
> >
> > David Cole wrote:
> > > Maybe save and restore the CMAKE_SHARED_LINKER_FLAGS
> around your
> > reset
> > > of it in the sub-CMakeLists.txt...?
> > >
> > >
> > > On Wed, Sep 3, 2008 at 10:41 AM, Martin Apel
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> > > <mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>>>
> > wrote:
> > >
> > > Hi,
> > >
> > > I have defined the following in a top-level
> CMakeLists.txt:
> > >  SET (CMAKE_SHARED_LINKER_FLAGS
> "${CMAKE_SHARED_LINKER_FLAGS}
> > > -Wl,--unresolved-symbols=ignore-in-shared-libs")
> > >
> > > Now I'd like to reset this for one specific library in a
> > subdirectory
> > > (in a separate CMakeLists.txt added with
> ADD_SUBDIRECTORY to
> > the main
> > > CMakeLists.txt). I tried to use
> > >  SET_TARGET_PROPERTIES (FortranInterface PROPERTIES
> LINK_FLAGS
> > > -Wl,--unresolved-symbols=ignore-in-object-files")
> > > which reverses the effect of "ignore-in-shared-libs".
> > > Unfortunately the
> &g

Re: [CMake] Override of link flag for one specific shared library

[Martin Apel]

I am using ADD_SUBDIRECTORY. I did'nt know, that anything like SUBDIRS
exists and haven't found anything in the documentation about it.

Martin


David Cole wrote:
> Are you using SUBDIRS or ADD_SUBDIRECTORY in your project...?
>
>
> On Thu, Sep 4, 2008 at 2:42 AM, Martin Apel <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Unfortunately this does not work. It seems that CMake generates all
> libraries defined in one CMakeLists.txt with the setting of
> CMAKE_SHARED_LINKER_FLAGS at the end of the file.
> This causes this setting to be applied to all libraries in the
> CMakeLists.txt. As I have 4 libraries in this one CMakeLists.txt, this
> doesn't help much.
>
> I tried to do something like the following:
> SET (CMAKE_SHARED_LINKER_FLAGS "${ORIG_SHARED_LINKER_FLAGS}")
> ADD_LIBRARY (FortranInterface ${OBJS})
> SET (CMAKE_SHARED_LINKER_FLAGS "${MODIFIED_SHARED_LINKER_FLAGS}")
> but the FortranInterface library gets built with
> MODIFIED_SHARED_LINKER_FLAGS in effect.
>
> I would suggest to change the order of items in the build rules for a
> future CMake release, such that it's possible to override general
> flags
> with a target specific property. Today the link
> rules look as follows:
> SET(CMAKE_CXX_CREATE_SHARED_LIBRARY " ...
>   ")
> >From my point of view it would be better to put LINK_FLAGS to the
> end of
> the list (not only for shared libraries, but in general).
>
> Regards,
>
> Martin
>
> David Cole wrote:
> > Maybe save and restore the CMAKE_SHARED_LINKER_FLAGS around your
> reset
> > of it in the sub-CMakeLists.txt...?
> >
> >
> > On Wed, Sep 3, 2008 at 10:41 AM, Martin Apel
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
> wrote:
> >
> > Hi,
> >
> > I have defined the following in a top-level CMakeLists.txt:
> >  SET (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> > -Wl,--unresolved-symbols=ignore-in-shared-libs")
> >
> > Now I'd like to reset this for one specific library in a
> subdirectory
> > (in a separate CMakeLists.txt added with ADD_SUBDIRECTORY to
> the main
> > CMakeLists.txt). I tried to use
> >  SET_TARGET_PROPERTIES (FortranInterface PROPERTIES LINK_FLAGS
> > -Wl,--unresolved-symbols=ignore-in-object-files")
> > which reverses the effect of "ignore-in-shared-libs".
> > Unfortunately the
> > linker rule contains the LINK_FLAGS before
> > CMAKE_SHARED_LINKER_FLAGS, so
> > this cannot be used to override the setting. I have also tried
> > resetting
> > CMAKE_SHARED_LINKER_FLAGS in the sub-CMakeLists.txt, but then it
> > applies
> > to all other
> > libraries handled in this CMakeLists.txt as well.
> >
> > Any ideas, how I can solve this problem?
> >
> > Regards,
> >
> > Martin
> >
> > 
> > Virus checked by G DATA AntiVirus
> > Version: AVF 19.21 from 03.09.2008
> >
> >
> > ___
> > CMake mailing list
> > CMake@cmake.org <mailto:CMake@cmake.org>
> <mailto:CMake@cmake.org <mailto:CMake@cmake.org>>
> > http://www.cmake.org/mailman/listinfo/cmake
> >
> >
>
>
> --
>
> Martin Apel Tel: 0049 8153
> 9288-47
> Software Architect  E-Mail:
>  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
> INTEC GmbH  Tel: 0049 8153
> 9288-0
> Argelsrieder Feld 13Fax: 0049 8153
> 9288-11
> 82234 Wessling  E-Mail:
>  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> Germany URL:
> http://www.simpack.com
>
> 
> Virus checked by G DATA AntiVirus
> Version: AVF 19.22 from 03.09.2008
>
>
>



Virus checked by G DATA AntiVirus
Version: AVF 19.27 from 07.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Override of link flag for one specific shared library

[Martin Apel]

Unfortunately this does not work. It seems that CMake generates all
libraries defined in one CMakeLists.txt with the setting of
CMAKE_SHARED_LINKER_FLAGS at the end of the file.
This causes this setting to be applied to all libraries in the
CMakeLists.txt. As I have 4 libraries in this one CMakeLists.txt, this
doesn't help much.

I tried to do something like the following:
SET (CMAKE_SHARED_LINKER_FLAGS "${ORIG_SHARED_LINKER_FLAGS}")
ADD_LIBRARY (FortranInterface ${OBJS})
SET (CMAKE_SHARED_LINKER_FLAGS "${MODIFIED_SHARED_LINKER_FLAGS}")
but the FortranInterface library gets built with
MODIFIED_SHARED_LINKER_FLAGS in effect.

I would suggest to change the order of items in the build rules for a
future CMake release, such that it's possible to override general flags
with a target specific property. Today the link
rules look as follows:
SET(CMAKE_CXX_CREATE_SHARED_LIBRARY " ...
  ")
>From my point of view it would be better to put LINK_FLAGS to the end of
the list (not only for shared libraries, but in general).

Regards,

Martin

David Cole wrote:
> Maybe save and restore the CMAKE_SHARED_LINKER_FLAGS around your reset
> of it in the sub-CMakeLists.txt...?
>
>
> On Wed, Sep 3, 2008 at 10:41 AM, Martin Apel <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hi,
>
> I have defined the following in a top-level CMakeLists.txt:
>  SET (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
> -Wl,--unresolved-symbols=ignore-in-shared-libs")
>
> Now I'd like to reset this for one specific library in a subdirectory
> (in a separate CMakeLists.txt added with ADD_SUBDIRECTORY to the main
> CMakeLists.txt). I tried to use
>  SET_TARGET_PROPERTIES (FortranInterface PROPERTIES LINK_FLAGS
> -Wl,--unresolved-symbols=ignore-in-object-files")
> which reverses the effect of "ignore-in-shared-libs".
> Unfortunately the
> linker rule contains the LINK_FLAGS before
> CMAKE_SHARED_LINKER_FLAGS, so
> this cannot be used to override the setting. I have also tried
> resetting
> CMAKE_SHARED_LINKER_FLAGS in the sub-CMakeLists.txt, but then it
> applies
> to all other
> libraries handled in this CMakeLists.txt as well.
>
> Any ideas, how I can solve this problem?
>
> Regards,
>
> Martin
>
> 
> Virus checked by G DATA AntiVirus
> Version: AVF 19.21 from 03.09.2008
>
>
> ___
> CMake mailing list
> CMake@cmake.org <mailto:CMake@cmake.org>
> http://www.cmake.org/mailman/listinfo/cmake
>
>


-- 

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com


Virus checked by G DATA AntiVirus
Version: AVF 19.22 from 03.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Override of link flag for one specific shared library

[Martin Apel]

Hi,

I have defined the following in a top-level CMakeLists.txt:
  SET (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
-Wl,--unresolved-symbols=ignore-in-shared-libs")

Now I'd like to reset this for one specific library in a subdirectory
(in a separate CMakeLists.txt added with ADD_SUBDIRECTORY to the main
CMakeLists.txt). I tried to use
  SET_TARGET_PROPERTIES (FortranInterface PROPERTIES LINK_FLAGS
-Wl,--unresolved-symbols=ignore-in-object-files")
which reverses the effect of "ignore-in-shared-libs". Unfortunately the
linker rule contains the LINK_FLAGS before CMAKE_SHARED_LINKER_FLAGS, so
this cannot be used to override the setting. I have also tried resetting
CMAKE_SHARED_LINKER_FLAGS in the sub-CMakeLists.txt, but then it applies
to all other
libraries handled in this CMakeLists.txt as well.

Any ideas, how I can solve this problem?

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.21 from 03.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Recoverable build errors?

[Martin Apel]

Convey, Christian J CIV NUWC NWPT wrote:
>
> I've got a top-level CMake project with numerous executable and
> library sub-projects.  I'd like to have CMake generate Makefiles such
> that if one of those subprojects fails the build process, the Makefile
> still attempts to build all other subprojects that aren't dependent on
> any of those which failed to build.
>
> Is this possible?
>
> Thanks,
> Christian
>
> 
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
This is not a CMake issue. You should simply invoke 'make -k', so make
keeps on going upon failures. You could even call 'make -i', which will
also try to build dependent targets, which cannot succeed.

Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVF 19.18 from 02.09.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Mixing C and Fortran object in same library with MSVC

[Martin Apel]

Hi,

I am trying to generate a DLL on Windows, which contains objects from C 
source files as well as Fortran source files. When using the nmake 
generator of cmake 2.6.0, everything works fine, as well as under Linux. 
However when using the Visual Studio 8 generator, only the C sources are 
compiled, not the Fortran sources. I suspect this is a bug in MSVC, 
because the generated .vcproj file contains the Fortran files, but MSVC 
shows "Custom Build Tool" for the compiler, when selecting "Properties" 
on a Fortran source file. Or is this a bug in CMake?

Any help would be very much appreciated.

Regards,

Martin
--


Virus checked by G DATA AntiVirus
Version: AVKA 18.346 from 28.07.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] detection of min version in findBoost

[Martin Apel]

Hi all,

if I remember right, FindBoost currently ignores the minimum version 
given. I had a similar problem myself and fell into the same trap.


Regards,

Martin

nilitonilito nilitonilito wrote:

Hi there,

I'm trying to detect libboost in my CMake root script, it works except 
for min version, I can put any kind of min version it always pass the 
test, I don't understand what I'm doing wrong?


here is a snippet of my script :

SET(BOOST_MIN_VERSION "2.33.2")

FIND_PACKAGE(Boost REQUIRED)

if (NOT Boost_FOUND)
  message(FATAL_ERROR "Fatal error: Boost (version >= x.x.x) 
required.\n"

  )
endif (NOT Boost_FOUND)



That script does not halt and my version of Boost is 1.33.1, whatever 
I put as BOOST_MIN_VERSION it keeps on. I also tried to replace 
BOOST_MIN_VERSION by Boost_MIN_VERSION but same result.


Thanks for your help
Regards
Nil



Avec une webcam et Messenger partagez vos émotions en vidéo ! 
Téléchargez gratuitement ! 



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake



--


Virus checked by G DATA AntiVirus
Version: AVKA 18.330 from 18.07.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on VisualStudio?

[Martin Apel]

Bill Hoffman wrote:

Martin Apel wrote:
This is it! It seems to work correctly, when using cd instead of "cd 
.". It seems I misinterpreted a command line parameter of a linker 
call as the directory output. Sorry for the confusion.

I'm not exactly in love with Windows ;-)



OK, but it is not using the working directory?

-Bill

Yes, it is using the correct directory. It was the perl script, which 
was called from add_custom_command, which had problems with its 
directory, due to a missing "pwd" command on Windows.

To sum up, it was all my fault :-)

Best Regards,

Martin



Virus checked by G DATA AntiVirus
Version: AVKA 18.309 from 27.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on VisualStudio?

[Martin Apel]

This is it! It seems to work correctly, when using cd instead of "cd .". 
It seems I misinterpreted a command line parameter of a linker call as 
the directory output. Sorry for the confusion.

I'm not exactly in love with Windows ;-)

Martin

David Cole wrote:
Try just "cd" -- cd . does not give any output at all, it's just a 
no-op... cd without any arguments prints the current working directory 
just like pwd...





On Fri, Jun 27, 2008 at 9:20 AM, Bill Hoffman 
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:


Martin Apel wrote:

    Bill Hoffman wrote:

Martin Apel wrote:

Hi Brad,

this is kind of difficult under Windows, as far as I
know. I have MSys installed on my machine, but the pwd
"command" is not really a command (i.e. .exe) under
MSys, but a shell script, which invokes
the shell command "pwd". Windows sees the file with
the "pwd" command in C:\MSys\bin as an ordinary file,
not an executable. So I cannot call this from within
ADD_CUSTOM_COMMAND. As I am no Windows expert, I
haven't found any other way. Can you recommend a way,
how to do this?


cd .

Hi Bill,

this doesn't result in any output at all:
ADD_CUSTOM_COMMAND (COMMAND cd .
   
 WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})


I think "cd ." cannot work, because there is no cd.exe under
Windows. I even tried "C:/WINNT/System32/cmd.exe /C cd .", but
this didn't work either.


It does work.   The output is going to be in that html file that
visual studio creates when it does the build.  I think you have to
cntrl-click to see it.

-Bill

___
CMake mailing list
    CMake@cmake.org <mailto:CMake@cmake.org>
http://www.cmake.org/mailman/listinfo/cmake





--

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com



Virus checked by G DATA AntiVirus
Version: AVKA 18.309 from 27.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on VisualStudio?

[Martin Apel]

Bill Hoffman wrote:

Martin Apel wrote:

Bill Hoffman wrote:

Martin Apel wrote:

Hi Brad,

this is kind of difficult under Windows, as far as I know. I have 
MSys installed on my machine, but the pwd "command" is not really a 
command (i.e. .exe) under MSys, but a shell script, which invokes
the shell command "pwd". Windows sees the file with the "pwd" 
command in C:\MSys\bin as an ordinary file, not an executable. So I 
cannot call this from within ADD_CUSTOM_COMMAND. As I am no Windows 
expert, I haven't found any other way. Can you recommend a way, how 
to do this?




cd .

Hi Bill,

this doesn't result in any output at all:
ADD_CUSTOM_COMMAND (COMMAND cd .
  WORKING_DIRECTORY 
${CMAKE_CURRENT_BINARY_DIR})


I think "cd ." cannot work, because there is no cd.exe under Windows. 
I even tried "C:/WINNT/System32/cmd.exe /C cd .", but this didn't 
work either.




It does work.   The output is going to be in that html file that 
visual studio creates when it does the build.  I think you have to 
cntrl-click to see it.


-Bill

I finally found it. I had already looked at the build output, but as 
there was a new-line missing and I simply added it to the 
CMakeLists.txt, where I needed it, so it was buried in other output. Sorry.
Anyway, the directory is always equal to ${EXECUTABLE_OUTPUT_PATH}, no 
matter what I specify as WORKING_DIRECTORY in ADD_CUSTOM_COMMAND.


Regards,

Martin


--

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com



Virus checked by G DATA AntiVirus
Version: AVKA 18.309 from 27.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on VisualStudio?

[Martin Apel]

Bill Hoffman wrote:

Martin Apel wrote:

Hi Brad,

this is kind of difficult under Windows, as far as I know. I have 
MSys installed on my machine, but the pwd "command" is not really a 
command (i.e. .exe) under MSys, but a shell script, which invokes
the shell command "pwd". Windows sees the file with the "pwd" command 
in C:\MSys\bin as an ordinary file, not an executable. So I cannot 
call this from within ADD_CUSTOM_COMMAND. As I am no Windows expert, 
I haven't found any other way. Can you recommend a way, how to do this?




cd .

Hi Bill,

this doesn't result in any output at all:
ADD_CUSTOM_COMMAND (COMMAND cd .
  WORKING_DIRECTORY 
${CMAKE_CURRENT_BINARY_DIR})


I think "cd ." cannot work, because there is no cd.exe under Windows. I 
even tried "C:/WINNT/System32/cmd.exe /C cd .", but this didn't work either.


Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVKA 18.309 from 27.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on VisualStudio?

[Martin Apel]

Hi Brad,

this is kind of difficult under Windows, as far as I know. I have MSys 
installed on my machine, but the pwd "command" is not really a command 
(i.e. .exe) under MSys, but a shell script, which invokes
the shell command "pwd". Windows sees the file with the "pwd" command in 
C:\MSys\bin as an ordinary file, not an executable. So I cannot call 
this from within ADD_CUSTOM_COMMAND. As I am no Windows expert, I 
haven't found any other way. Can you recommend a way, how to do this?


Regards,

Martin

Brad King wrote:

Martin Apel wrote:
  

  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}



For VS this is the default working directory if no WORKING_DIRECTORY is
given.

  

This calls a perl script to generate a bunch of Fortran files as needed.
This script has to run in the output directory. I have checked the
generated .vcproj file and it doesn't contain anything related to
the working directory for this command. I modified the command to use
  COMMAND ${CMAKE_COMMAND} -E chdir ${PERL_EXECUTABLE}
${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
and now it works properly. But still, my impression is, that the Visual
Studio generator ignores this parameter.



Have you tried a custom command that just prints the working directory
to see where it is?

-Brad

  



--

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com



Virus checked by G DATA AntiVirus
Version: AVKA 18.309 from 27.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on Visual Studio?

[Martin Apel]

Hi Bill

I simply do the following:

ADD_CUSTOM_COMMAND(OUTPUT ${FSrcWithBinDir} 
${CMAKE_CURRENT_BINARY_DIR}/accessor_protos.h
  COMMAND ${CMAKE_COMMAND} -E copy_if_different 
${CMAKE_CURRENT_SOURCE_DIR}/FortranModules.inp  
${CMAKE_CURRENT_BINARY_DIR}/FortranModules.inp
  COMMAND ${CMAKE_COMMAND} -E copy_if_different 
${CMAKE_CURRENT_SOURCE_DIR}/FortranCommons.inp  
${CMAKE_CURRENT_BINARY_DIR}/FortranCommons.inp
  COMMAND ${PERL_EXECUTABLE} 
${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
  DEPENDS 
${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl FortranModules.inp 
FortranCommons.inp ${ModuleDefs} ${CommonDefs}

  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  )

This calls a perl script to generate a bunch of Fortran files as needed. 
This script has to run in the output directory. I have checked the 
generated .vcproj file and it doesn't contain anything related to

the working directory for this command. I modified the command to use
  COMMAND ${CMAKE_COMMAND} -E chdir ${PERL_EXECUTABLE} 
${CMAKE_SOURCE_DIR}/scripts/createFortAccessors.pl
and now it works properly. But still, my impression is, that the Visual 
Studio generator ignores this parameter.


Regards,

Martin


Bill Hoffman wrote:

Martin Apel wrote:

Hi all,

I got the impression, that the CMake generator for Visual Studio 7 
ignores the working directory set in ADD_CUSTOM_COMMAND. Is this a 
bug or is this a documented feature somehow?

Or am I simply doing something wrong?

Might be a bug, might be you.  Please provide a small example that 
shows the problem.


-Bill




--

Martin Apel Tel: 0049 8153 9288-47
Software Architect  E-Mail:  [EMAIL PROTECTED]

INTEC GmbH  Tel: 0049 8153 9288-0
Argelsrieder Feld 13Fax: 0049 8153 9288-11
82234 Wessling  E-Mail:  [EMAIL PROTECTED]
Germany URL: http://www.simpack.com

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] WORKING_DIRECTORY ignored for ADD_CUSTOM_COMMAND on Visual Studio?

[Martin Apel]

Hi all,

I got the impression, that the CMake generator for Visual Studio 7 
ignores the working directory set in ADD_CUSTOM_COMMAND. Is this a bug 
or is this a documented feature somehow?

Or am I simply doing something wrong?

Regards,

Martin



Virus checked by G DATA AntiVirus
Version: AVKB 18.324 from 26.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Missing header files in Visual Studio project

[Martin Apel]

Hi all,

I am using the CMake generator for Visual Studio 2005 to generate 
multiple projects. CMake generates one project file per library, which 
is fine. When looking at a generated project inside Visual Studio the
project tree contains "Header files" and "Source files". Strange is, 
that under "Header files" only generated headers are listed, not any 
other headers, which are part of the source code. The "source files" 
entry contains all source files for this library. I create the library 
by doing something like
ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc} ${GenCppFiles} 
${GenHFiles})


Do I have to add the normal header files in ADD_LIBRARY as well, so 
Visual Studio will list them? I would have expected CMake to 
automatically generate the list from the dependencies. What might be of 
interest as well (though I don't think it makes any difference), is that 
I explicitly set the regular expression to use for includes to

 INCLUDE_REGULAR_EXPRESSION ("\\.h$")
mainly to eliminate boost header files from the dependencies.

CMake version is 2.6.0.

Any thoughts on this are appreciated.

Regards,

Martin



Virus checked by G DATA AntiVirus
Version: AVKB 18.323 from 25.06.2008


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] GCC version variable

[Martin Apel]

Mike Jackson wrote:
This is taken from a FindBoost.cmake file I had laying around. Adjust 
for your needs:


 EXEC_PROGRAM(${CMAKE_CXX_COMPILER}
ARGS --version
OUTPUT_VARIABLE _boost_COMPILER_VERSION
)
STRING(REGEX REPLACE ".* ([0-9])\\.([0-9])\\.[0-9] .*" 
"\\1\\2"

   _boost_COMPILER_VERSION ${_boost_COMPILER_VERSION})
SET (_boost_COMPILER "-gcc${_boost_COMPILER_VERSION}")



Don't use this regular expression to find out the GCC version!
I filed a bug report for FindBoost.cmake 
(http://public.kitware.com/Bug/view.php?id=7097) some weeks ago, that 
this doesn't work reliably.
I built GCC myself with a suffix of -32, which confuses the regular 
expression above. As a workaround I modified my local FindBoost.cmake to 
use
 STRING(REGEX REPLACE ".* ([0-9])\\.([0-9])\\.[0-9].*" "\\1\\2"  
_boost_COMPILER_VERSION ${_boost_COMPILER_VERSION})

Note the blank after the initial ".*"!


Regards,

Martin


Virus checked by G DATA AntiVirus
Version: AVKA 18.302 from 18.06.2008
Virus news: www.antiviruslab.com

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to set platform-specific compiler-options from within CMakeFiles

[Martin Apel]

Mike Jackson wrote:
typically, the PROJECT() statement is the first line of your 
CMakeLists.txt. Could you explain your project layout a bit more?



I found out, that CMAKE_CXX_FLAGS is set to the compound of 
$ENV{CXXFLAGS} and the platform-specific default at the time, the 
PROJECT statement is executed.
In order to preset CMAKE_CXX_FLAGS I tried to set $ENV{CXXFLAGS} from 
within the CMakeFile. Thus this setting has to be done before the 
PROJECT statement, otherwise

CMAKE_CXX_FLAGS is already set. So I tried to include an external file by
INCLUDE (${CMAKE_SYSTEM_NAME}.cmake)
before the PROJECT statement. This doesn't work, because 
${CMAKE_SYSTEM_NAME} is not set at that time.


When setting CMAKE_CXX_FLAGS after the PROJECT statement, the 
CMake-local variable is set correctly, but the cache is not updated. The 
situation I tried to achieve, was to preset
the cache variable CMAKE_CXX_FLAGS to include certain compiler flags. If 
the user looked at the cache e.g. by using ccmake, he would also see and 
be able to edit those additional flags.
By setting the flags later, you only change the CMake-local variable, 
but never the cache value, which is somewhat irritating, because the 
compile happens with other flags than can be seen using

ccmake.

Martin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to set platform-specific compiler-options from within CMakeFiles

[Martin Apel]

Thanks for your help. The problem is, that CMAKE_SYSTEM is not set at 
the time the INCLUDE statement is necessary. The PROJECT statement seems 
to cause it to be defined and at the same time sets the compiler flags. 
If I put the INCLUDE before PROJECT, then CMAKE_SYSTEM is not available, 
only defines like WIN32. If I put the INCLUDE after PROJECT the compiler 
flags are already defined, so I cannot add any initial flags anymore. To 
me it looks like a bug in CMake, that CMAKE_SYSTEM and CMAKE_SYSTEM_NAME 
are not defined until the PROJECT statement.
Simply appending flags to CMAKE_CXX_FLAGS after the PROJECT statement 
probably would work, but ccmake would not show these options, because 
the will never reach the cache. It seems I have to resort to this approach.


Best Regards,

Martin

Mike Jackson wrote:

Sure you can:
 INCLUDE (MSVC_Compiler_Stuff.cmake)

#--MSVC_Compiler_Stuff.cmake
if (MSVC)

endif (MSVC)


I do this all the time for OS X specific stuff.

For Linux you can try:

IF(CMAKE_SYSTEM MATCHES "Linux-([3-9]\\.[0-9]|2\\.[4-9])\\.")
  # Linux Specific flags

ENDIF(CMAKE_SYSTEM MATCHES "Linux-([3-9]\\.[0-9]|2\\.[4-9])\\.")

if you are using ICC on linux you can also test for that:

IF( ${CMAKE_C_COMPILER} MATCHES "icc" )
SET(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -static-intel)
ENDIF( ${CMAKE_C_COMPILER} MATCHES "icc" )

or test for GCC:

IF(CMAKE_COMPILER_IS_GNUCC)
  SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fmessage-length=0")
ENDIF(CMAKE_COMPILER_IS_GNUCC)
IF(CMAKE_COMPILER_IS_GNUCXX)
  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fmessage-length=0")
ENDIF(CMAKE_COMPILER_IS_GNUCXX)


Hope that helps a bit

-- Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 5, 2008, at 11:21 AM, Martin Apel wrote:

Unfortunately I cannot simply add one file with platform specifics 
for each additional platform. Instead I have to clutter up the main 
CMakeLists.txt with if statements.
Especially there is no way to support platforms for which no 
explicitly testable variable is available e.g. Linux.
Strange enough is, that WIN32 is set before the PROJECT statement, 
while CMAKE_SYSTEM_NAME is not.


Martin

Mike Jackson wrote:

IF (WIN32)
SET(..)
ENDIF (WIN32)

IF (MSVC)

ENDIF (MSVC)
-- Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jun 5, 2008, at 10:35 AM, Martin Apel wrote:


Hi all,

I am trying to set the CMAKE_CXX_FLAGS or CMAKE_CXX_FLAGS_INIT 
variable, such that it contains flags to turn off specific warnings 
for the Visual Studio compiler. I definitely want to set these 
additional flags from within a CMakeFile, specifying them on the 
command line or interactively is not an option.

I have included a Windows-specific file by using
INCLUDE (${CMAKE_SYSTEM_NAME}.cmake)

The file Windows.cmake contains the line
SET (ENV{CXXFLAGS} "/wd4251")

However this only works after the PROJECT line within the 
CMakeFile, because before it CMAKE_SYSTEM_NAME seems to be unset. 
On the other hand, when writing the include statement after the 
project command, the CMAKE_CXX_FLAGS seem already to be set. If 
possible I would like to specify those flags as initial values, 
avoiding to use the force option of the set command.


What is the recommended way to add platform-specific compiler flags 
from within CMakeFiles?


Any help would be appreciated.

Martin

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake






--

Martin Apel Tel: 0049 8153 
9288-47
Software Architect  E-Mail:  
[EMAIL PROTECTED]


INTEC GmbH  Tel: 0049 8153 
9288-0
Argelsrieder Feld 13Fax: 0049 8153 
9288-11
82234 Wessling  E-Mail:  
[EMAIL PROTECTED]
Germany URL: 
http://www.simpack.com








___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to set platform-specific compiler-options from within CMakeFiles

[Martin Apel]

Hi all,

I am trying to set the CMAKE_CXX_FLAGS or CMAKE_CXX_FLAGS_INIT variable, 
such that it contains flags to turn off specific warnings for the Visual 
Studio compiler. I definitely want to set these additional flags from 
within a CMakeFile, specifying them on the command line or interactively 
is not an option.

I have included a Windows-specific file by using
INCLUDE (${CMAKE_SYSTEM_NAME}.cmake)

The file Windows.cmake contains the line
SET (ENV{CXXFLAGS} "/wd4251")

However this only works after the PROJECT line within the CMakeFile, 
because before it CMAKE_SYSTEM_NAME seems to be unset. On the other 
hand, when writing the include statement after the project command, the 
CMAKE_CXX_FLAGS seem already to be set. If possible I would like to 
specify those flags as initial values, avoiding to use the force option 
of the set command.


What is the recommended way to add platform-specific compiler flags from 
within CMakeFiles?


Any help would be appreciated.

Martin

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Import library not generated under Visual Studio

[Martin Apel]

Christian Ehrlicher wrote:

Von: Martin Apel
Hi all,

I am trying to port a project using CMake 2.6 from Linux to Windows. The 
project build works without problems under Linux. However when trying to 
build the project inside Visual Studio 8 after having generated the 
project files using CMake, no import libraries are generated.

The library build step is specified by using
  ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc})
which I would expect to generate rules to create the DLL AND the 
corresponding import library. The DLL is built, but the import library 
is missing. Looking at the build log file in Visual Studio, there is no 
call to lib.exe, which I would expect.
I am not a Windows specialist, so I may be missing something simple 
completely.


Any help would be appreciated.



cmake itself does not do anything to create an import lib. This is all done by 
the linker. If it finds symbols which are exported, it automatically creates 
the import lib.
So it looks like you don't export any symbols.


Christian

  
Thanks for your help. I found out, that I had written the macro 
containing declspec(export) enclosed by #ifdef WINDOWS instead of #ifdef 
WIN32. As a result no symbols were exported, so no import library was 
generated.


Best Regards,

Martin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Import library not generated under Visual Studio

[Martin Apel]

Hi all,

I am trying to port a project using CMake 2.6 from Linux to Windows. The 
project build works without problems under Linux. However when trying to 
build the project inside Visual Studio 8 after having generated the 
project files using CMake, no import libraries are generated.

The library build step is specified by using
 ADD_LIBRARY(Base SHARED EXCLUDE_FROM_ALL ${LocalSrc})
which I would expect to generate rules to create the DLL AND the 
corresponding import library. The DLL is built, but the import library 
is missing. Looking at the build log file in Visual Studio, there is no 
call to lib.exe, which I would expect.
I am not a Windows specialist, so I may be missing something simple 
completely.


Any help would be appreciated.

Martin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Custom-Targets with unknown outputs

[Martin Apel]

Christoph Cullmann wrote:

Am Mittwoch 14 Mai 2008 16:30:24 schrieben Sie:
  

Are you sure the generated source file names are completely unpredictable?
Unless some random generator is being used, those names are probably
predictable, and it might be worth your while to look further into figuring
out how you can do that.

The only thing predictable is the output directory (where atm a Makefile is 
placed which we use with gmake + link the resulting library in the toplevel 
makefile, as that name is known, too.). We can't predict them, as the code 
generator generates one file per datatype and the datatypes are dynamic 
dependend of the input file. To perdict them, in fact, the generator would 
have to run.



  
That's what I did for a similar problem: I modified the generator to 
output a list of generated files, when called with a special command 
line switch.
In this case the generator only generates the file list, not the files 
themselves. I ran this via EXECUTE_PROCESS at configuration time, so you 
have

the names of the generated files in a variable.
Of course this only works if you are able to modify the generator.

Martin
--
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to link executable with libraries containing circulardependencies

[Martin Apel]

Newell, James C. wrote:

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Martin Apel
Sent: Tuesday, April 22, 2008 9:06 AM
To: cmake@cmake.org
Subject: [CMake] How to link executable with libraries containing
circulardependencies

Hi there,

I am trying to link an executable with multiple libraries, which
reference each other in a circular fashion. It seems, that I cannot
specify the same library multiple times
in TARGET_LINK_LIBRARIES, so the link line will always end up with


each
  

library listed exactly once. In my case, this leads to unresolved
symbols.
I know that circular dependencies are not nice, but it's a large
"inherited" project I would like to convert to use CMake.
I posted this issue before, trying to resolve it using the --start-
group
and --end-group options to the linker, but haven't gotten any


responses
  

yet.
To me it looks, as if CMake is not able to handle linker calls with
circular references. Any pointers?

Regards,



I solved it by using the 'add_custom_target'.  The example below isn't
generic, but could be made so with a bit more work and the example
assumes the main is contained in one of the libx.a and I used the cxx
instead of c compiler.

project(myproj)

set(mylibs
lib1.a
lib2.a
lib3.a)

foreach(libs ${mylibs})
  set(userlibs ${uselibs} somepath/${libs})
endforeach(libs)

add_custom_target(mymain ALL ${CMAKE_CXX_COMPILER} -g -o mymain
-Wl,--start-group ${uselibs} -Wl,--end-group ${MY_LINK_FLAGS})

Regards,
Jim

  

Hi Jim,

thanks for your reply. I tried this approach myself, but the problem 
with it is, that you also have to define custom commands for generating 
the object file containing the main function,
which should rather not be contained in a library. Otherwise one of the 
libraries has to contain exactly one main function, which probably leads 
to creating one additional library for each main

program in the system, which is not nice.

Regards,

Martin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to link executable with libraries containing circular dependencies

[Martin Apel]

Hi there,

I am trying to link an executable with multiple libraries, which 
reference each other in a circular fashion. It seems, that I cannot 
specify the same library multiple times
in TARGET_LINK_LIBRARIES, so the link line will always end up with each 
library listed exactly once. In my case, this leads to unresolved symbols.
I know that circular dependencies are not nice, but it's a large 
"inherited" project I would like to convert to use CMake.
I posted this issue before, trying to resolve it using the --start-group 
and --end-group options to the linker, but haven't gotten any responses yet.
To me it looks, as if CMake is not able to handle linker calls with 
circular references. Any pointers?


Regards,

Martin

--
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to tell CMake to use --start-group and --end-group during linking?

[Martin Apel]

Hi,

I am currently trying to convert a big project containing Fortran and C 
sources to use CMake. There are lots of circular dependencies between 
libraries,
so I either have to specify libraries on the link line multiple times or 
use the linker options --start-group and --end-group for ld on Linux.
It seems that CMake throws out multiple references to the same library 
in the TARGET_LINK_LIBRARIES statement, but anyway I would rather use
--start-group and --end-group, so I don't have to hunt down all those 
dependencies explicitly. Is there any way to make CMake use these options?
It is important to specify them on the right place on the command line, 
i.e. --start-group before the first library and --end-group after the 
last relevant.


Regards,

Martin
--
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake