[cmake-developers] [CMake 0012215]: CMake Not Detecting Basic Fortran Dependencies
The following issue has been SUBMITTED. == http://www.vtk.org/Bug/view.php?id=12215 == Reported By:Mohamad Sindi Assigned To: == Project:CMake Issue ID: 12215 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-05-23 13:54 AST Last Modified: 2011-05-23 13:54 AST == Summary:CMake Not Detecting Basic Fortran Dependencies Description: I have the below directory structure for Fortran code which has very basic dependencies, yet CMake seems to fail to recognize the dependencies: src/ CMakeLists.txt lib1/CMakeLists.txt lib1/lib1.f lib2/CMakeLists.txt lib2/lib2.f lib3/CMakeLists.txt lib3/lib3.f main/CMakeLists.txt main/myMain.f Dependencies are: myMain uses lib3 lib3 uses lib2 lib2 uses lib1 My top directory CMakeLists.txt looks like this: [sindimo@lnx src]$ cat CMakeLists.txt CMAKE_MINIMUM_REQUIRED (VERSION 2.8) PROJECT(Fortran-Example-Dependency-Failure Fortran) INCLUDE_DIRECTORIES(/workspace/Fortran-Example-Dependency-Failure/obj/linux_gnu_release_64-bit) set (EXECUTABLE_OUTPUT_PATH /workspace/Fortran-Example-Dependency-Failure/bin/linux_gnu_release_64-bit) set (LIBRARY_OUTPUT_PATH /workspace/Fortran-Example-Dependency-Failure/obj/linux_gnu_release_64-bit) set (CMAKE_Fortran_MODULE_DIRECTORY /workspace/Fortran-Example-Dependency-Failure/obj/linux_gnu_release_64-bit) ADD_SUBDIRECTORY(lib3) ADD_SUBDIRECTORY(lib2) ADD_SUBDIRECTORY(lib1) ADD_SUBDIRECTORY(main) The subdirectory CMakeLists.txt files look like: [sindimo@lnx src]$ cat lib1/CMakeLists.txt ADD_LIBRARY(lib1 SHARED lib1.f) [sindimo@lnx src]$ cat lib2/CMakeLists.txt ADD_LIBRARY(lib2 SHARED lib2.f) [sindimo@lnx src]$ cat lib3/CMakeLists.txt ADD_LIBRARY(lib3 SHARED lib3.f) [sindimo@lnx src]$ cat main/CMakeLists.txt ADD_EXECUTABLE(Fortran-Example-Dependency-Failure.exe myMain.f) TARGET_LINK_LIBRARIES(Fortran-Example-Dependency-Failure.exe lib1 lib2 lib3) When I run cmake followed by make I get the below error which apparently seems to be due to CMake not figuring out the correct dependencies in Fortran and doing the wrong build sequence: [sindimo@lnx build_linux_gnu_release_64-bit]$ cmake ../src -- The CXX compiler identification is GNU -- The Fortran compiler identification is GNU -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working Fortran compiler: /usr/bin/gfortran -- Check for working Fortran compiler: /usr/bin/gfortran -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/gfortran supports Fortran 90 -- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: /workspace/Fortran-Example-Dependency-Failure/build_linux_gnu_release_64-bit [sindimo@lnx build_linux_gnu_release_64-bit]$ make Scanning dependencies of target lib3 [ 25%] Building Fortran object lib3/CMakeFiles/lib3.dir/lib3.f.o In file /workspace/Fortran-Example-Dependency-Failure/src/lib3/lib3.f:6 use m_lib2 1 Fatal Error: Can't open module file 'm_lib2.mod' for reading at (1): No such file or directory make[2]: *** [lib3/CMakeFiles/lib3.dir/lib3.f.o] Error 1 make[1]: *** [lib3/CMakeFiles/lib3.dir/all] Error 2 make: *** [all] Error 2 To my understanding CMake should be able to handle such simple Fortran dependencies (as I recall, it uses similar intelligence to that of makedepf90), am I doing something wrong here or is this considered too complicated of a Fortran dependency for CMake to handle? As a work around, if I add the below dependency statements manually to the top level CMakeLists.txt file, things go well: ADD_DEPENDENCIES(lib2 lib1) ADD_DEPENDENCIES(lib3 lib2) Also if I sort the ADD_SUBDIRECTORY commands in the correct build sequence, that obviously solves the problem as well. However our actual application that we need to use CMake with consists of hundreds of libraries, so adding these dependencies manually or sorting them in the correct build sequence is not feasible. The Mastering CMake 4th edition book mentions an output_required_files command which should take a source file and produce
Re: [cmake-developers] Getting changes into master
On 05/21/2011 04:59 AM, Eric Noulard wrote: You don't merge to master yourself, Kitware guys do. If your merge to next did not make some dashboard go red. Dave, Brad, Bill co do review (something like every week on tuesday I think) the change which reached next which deserve to go to master. Correct. I just added a couple sentences describing this at the bottom of the section: http://www.cmake.org/Wiki/CMake/Git#Topic_Stage -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Newbie question: Static linking
On 23 May 2011 00:53, Hendrik Sattler p...@hendrik-sattler.de wrote:
Am Montag, 23. Mai 2011, 01:36:14 schrieb Sanatan Rai:
After cmake, and make all, the libraries build as static archives, ie I get
liblib1.a, liblib2.a, libhelper1.a, libhelper2.a and executable myProj in
the appropriate locations. However, the executable myProj does not appear
to have linked statically to libhelper1.a and libhelper2.a. These
libraries contain global initialisers for certain objects: which doesn't
happen when I run the executable.
Most likely, the linker just drops those global initialisers when linking
statically. See the linker options in man ld to prevent that or give the
library an initialisation method.
I don't understand: so why does it work at all? I guess what I
don't understand is that
I don't see symbols from helper1 and helper2 in the final executable,
when I build them
as separate libraries, but I do when I express the dependencies thus:
add_executable(myTarget target.cpp helpers/helper1.cpp helpers/helper2.cpp)
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called: which
suggests that the library was not loaded in memory. On the other hand,
when I build
them with the executable, the lines are called and everything works as expected.
I am not sure what else I can tell the linker. The libraries are
static so should be linked
statically. As far as I can tell, somehow the two helper libraries are
not being linked
at all.
Sorry, but I am quite confused.
--Sanatan
___
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] 2.8.5 version
Any news about the deadline of 2.8.5 release? Andrea Il 16/02/2011 11.52, Michael Wild ha scritto: On 02/16/2011 11:40 AM, Andrea Galeazzi wrote: IL 15/02/2011 21.59, David Cole ha scritto: 2011/2/15 Alexander Neundorfa.neundorf-w...@gmx.net mailto:a.neundorf-w...@gmx.net On Monday 14 February 2011, David Cole wrote: On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi galea...@korg.itmailto:galea...@korg.it wrote: I'm very interested in the feature discussed here: http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 will be released? Or better, do you have a periodic schedule planning the releases? You are correct. We will be releasing 2.8.4 very shortly... We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 will be released in May, 2011. We'll probably schedule a release candidate 1 trial build for late April. I have a local fix for the mentioned issue, but I thought I should not try to merge it now into next, since it is more like a feature and less like a bugfix. But I can do it you you#re ok with it. Alex You can push to the stage and merge to next whenever you like. That's one of the beauties of our new git workflow... Excuse me I'm a git newbie, I can't find the stage branch. do I misunderstand anything? You might want to read this: http://www.cmake.org/Wiki/CMake/Git Michael ___ 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 __ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 5878 (20110215) __ Il messaggio è stato controllato da ESET NOD32 Antivirus. www.nod32.it ___ 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] Newbie question: Static linking
Zitat von Sanatan Rai sana...@gmail.com:
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called.
Then you don't understand the implications of static libraries, yet.
Use the following from man ld:
--whole-archive
For each archive mentioned on the command line after the
--whole-archive option, include every object file in the archive in
the link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a shared
library, forcing every object to be included in the resulting
shared library. This option may be used more than once.
Two notes when using this option from gcc: First, gcc doesn't know
about this option, so you have to use -Wl,-whole-archive. Second,
don't forget to use -Wl,-no-whole-archive after your list of
archives, because gcc will add its own list of archives to your
link and you may not want this flag to affect those as well.
HS
___
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] Parallel build test problem
Hi all, A colleague of mine reported a bug in our CMake-base build system when doing a parallel build of multiple targets where one of the targets is 'test'. quote Running 'make -j16 tMutex test' (or any test other than tMutex) for example will result in building tMutex in parallel to testing it. Expected behaviour is first building tMutex, followed by running the tests. /quote Is this indeed a bug? Either in our build system or in CMake? AFAIK it is not possible to define dependencies between the 'test' target and the target to build the test program. Correct? Best regards, Marcel Loose. -- Marcel Loose Senior Software Engineer, Computing Group RD, Astron, the Netherlands ___ 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] Newbie question: Static linking
On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
Zitat von Sanatan Rai sana...@gmail.com:
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called.
Then you don't understand the implications of static libraries, yet.
Use the following from man ld:
--whole-archive
Foreach archive mentioned on the command line after
the
--whole-archive option, include every object file in the archive in
the link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a shared
library, forcing every object to be included inthe
resulting
shared library. This option may be used more than once.
Twonotes when using this option from gcc: First, gcc doesn't
know
about this option, so you have to use -Wl,-whole-archive. Second,
don't forget to use -Wl,-no-whole-archive after your
list of
archives, because gcc will add its own listof archives to
your
link and you may not want this flag to affect those as well.
HS
But this will only work when using GNU ld (or compatible). AFAIK the
linker on APPLE uses a different option, and MSVC doesn't have an
equivalent at all (you can only specify individual symbols that should
be linked forcibly).
The real solution is to ditch this whole idea of global, static
initialization objects. It's usually a very bad solution, leading to all
kinds of non-deterministic behavior. You'll be much better off with an
explicit registration scheme.
My 2c.
Michael
___
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] Newbie question: Static linking
On 23 May 2011 10:18, Michael Wild them...@gmail.com wrote:
On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
Zitat von Sanatan Rai sana...@gmail.com:
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called.
Then you don't understand the implications of static libraries, yet.
Use the following from man ld:
--whole-archive
For each archive mentioned on the command line after the
--whole-archive option, include every object file in the archive in
the link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a shared
library, forcing every object to be included in the
snipped
Thanks Hendrik, that works! For the record, I have added the following:
target_link_libraries(myTarget
-Wl,-whole-archive -L./helpers -lhelper1 -Wl,-no-whole-archive
-Wl,-whole-archive -L./helpers -lhelper2 -Wl,-no-whole-archive)
I am not happy about having to provide the search path explicitely, but hey.
But this will only work when using GNU ld (or compatible). AFAIK the
linker on APPLE uses a different option, and MSVC doesn't have an
equivalent at all (you can only specify individual symbols that should
be linked forcibly).
The real solution is to ditch this whole idea of global, static
initialization objects. It's usually a very bad solution, leading to all
kinds of non-deterministic behavior. You'll be much better off with an
explicit registration scheme.
My 2c.
Michael
I couldn't agree more. However, there does not appear to be an alternative
way of doing this registration. Briefly, here is the problem I am
trying to solve.
* I have a base class (say) myBase.
* I expect other users of my library to derive objects from myBase.
* The application `creates' the derived objects as per the pattern above,
based on which ones the user wants as per a config file.
* So: if the user specifies an object that is not built, then the app
is going to
throw an exception and abort.
* The whole point of doing this is that the application is a
`framework' for the
user `to host his derived class'.
This approach permits me to keep the application and the `framework' code
agnostic to the user's derived classes.
I'd be more than happy to find a better way of achieving the
framework's agnosticism
to the derived classes, while providing the user to derive whatever
objects he likes.
When I solved this problem on .NET I was forced to run through all the
assemblies
to find the relevant objects and then use reflection to instantiate
them. That was even
uglier.
Thanks all!
--Sanatan
--
Sanatan Rai
3, Admirals Court,
30, Horselydown Lane,
London, SE1 2LJ.
+44-20-7403-2479.
___
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] 2.8.5 version
If we can get the dashboards green enough in the Nightly Expected section, we will put out an rc1 release candidate this week. Thanks, David On Mon, May 23, 2011 at 4:00 AM, Andrea Galeazzi galea...@korg.it wrote: Any news about the deadline of 2.8.5 release? Andrea Il 16/02/2011 11.52, Michael Wild ha scritto: On 02/16/2011 11:40 AM, Andrea Galeazzi wrote: IL 15/02/2011 21.59, David Cole ha scritto: 2011/2/15 Alexander Neundorfa.neundorf-w...@gmx.net mailto:a.neundorf-w...@gmx.net On Monday 14 February 2011, David Cole wrote: On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi galea...@korg.itmailto:galea...@korg.it wrote: I'm very interested in the feature discussed here: http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 will be released? Or better, do you have a periodic schedule planning the releases? You are correct. We will be releasing 2.8.4 very shortly... We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 will be released in May, 2011. We'll probably schedule a release candidate 1 trial build for late April. I have a local fix for the mentioned issue, but I thought I should not try to merge it now into next, since it is more like a feature and less like a bugfix. But I can do it you you#re ok with it. Alex You can push to the stage and merge to next whenever you like. That's one of the beauties of our new git workflow... Excuse me I'm a git newbie, I can't find the stage branch. do I misunderstand anything? You might want to read this: http://www.cmake.org/Wiki/CMake/Git Michael ___ 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 __ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 5878 (20110215) __ Il messaggio è stato controllato da ESET NOD32 Antivirus. www.nod32.it ___ 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] Parallel build test problem
On Mon, May 23, 2011 at 4:13 AM, Marcel Loose lo...@astron.nl wrote: Hi all, A colleague of mine reported a bug in our CMake-base build system when doing a parallel build of multiple targets where one of the targets is 'test'. quote Running 'make -j16 tMutex test' (or any test other than tMutex) for example will result in building tMutex in parallel to testing it. Expected behaviour is first building tMutex, followed by running the tests. /quote Is this indeed a bug? Either in our build system or in CMake? AFAIK it is not possible to define dependencies between the 'test' target and the target to build the test program. Correct? Best regards, Marcel Loose. -- Marcel Loose Senior Software Engineer, Computing Group RD, Astron, the Netherlands ___ 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 To the best of my knowledge you can only do a parallel make of one target at a time. The best way to do what you want is to do two parallel make runs in sequence, like this: make -j16 tMutex make -j16 test The test target is defined by CMake, though, and runs all tests. HTH, David ___ 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] symstore
In my project there is a call to symstore.exe in build script. Sure you can add a target, but its not necessary imho. 2011/5/22 Paul Harris harris...@gmail.com: Hi, http://www.stackhash.com/blog/post/Setting-up-a-Symbol-Server.aspx I read this blog and thought it would be great to have cmake generate a SYMSTORE project in addition to the INSTALL project, which would add the pdb files to the symstore area. I googled and haven't heard anything about it anywhere else, in relation to cmake. How do cmake users manage debugging minidumps from users? thanks Paul ___ 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 -- BG, Alexey ___ 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] Parallel build test problem
On Mon, 2011-05-23 at 07:21 -0400, David Cole wrote: On Mon, May 23, 2011 at 4:13 AM, Marcel Loose lo...@astron.nl wrote: Hi all, A colleague of mine reported a bug in our CMake-base build system when doing a parallel build of multiple targets where one of the targets is 'test'. quote Running 'make -j16 tMutex test' (or any test other than tMutex) for example will result in building tMutex in parallel to testing it. Expected behaviour is first building tMutex, followed by running the tests. /quote Is this indeed a bug? Either in our build system or in CMake? AFAIK it is not possible to define dependencies between the 'test' target and the target to build the test program. Correct? Best regards, Marcel Loose. -- Marcel Loose Senior Software Engineer, Computing Group RD, Astron, the Netherlands ___ 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 To the best of my knowledge you can only do a parallel make of one target at a time. The best way to do what you want is to do two parallel make runs in sequence, like this: make -j16 tMutex make -j16 test The test target is defined by CMake, though, and runs all tests. HTH, David Hi David, I vaguely remembered that limitation of 'make' as well, but I couldn't find any relevant pointers on this, and colleagues questioned this alleged limitation. Therefore I thought it might be a limitation of CMake, or maybe I should say: the combination of CMake and make. Anyway, my response was also to do two separate 'make' calls, one for each target. Regards, Marcel Loose. ___ 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] Newbie question: Static linking
You might want to take a look at the Factory design pattern.
-
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
Sent from my mobile device.
On May 23, 2011, at 5:51, Sanatan Rai sana...@gmail.com wrote:
On 23 May 2011 10:18, Michael Wild them...@gmail.com wrote:
On 05/23/2011 10:23 AM, Hendrik Sattler wrote:
Zitat von Sanatan Rai sana...@gmail.com:
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called.
Then you don't understand the implications of static libraries, yet.
Use the following from man ld:
--whole-archive
Foreach archive mentioned on the command line after the
--whole-archive option, include every object file in the archive in
the link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a shared
library, forcing every object to be included inthe
snipped
Thanks Hendrik, that works! For the record, I have added the following:
target_link_libraries(myTarget
-Wl,-whole-archive -L./helpers -lhelper1 -Wl,-no-whole-archive
-Wl,-whole-archive -L./helpers -lhelper2 -Wl,-no-whole-archive)
I am not happy about having to provide the search path explicitely, but hey.
But this will only work when using GNU ld (or compatible). AFAIK the
linker on APPLE uses a different option, and MSVC doesn't have an
equivalent at all (you can only specify individual symbols that should
be linked forcibly).
The real solution is to ditch this whole idea of global, static
initialization objects. It's usually a very bad solution, leading to all
kinds of non-deterministic behavior. You'll be much better off with an
explicit registration scheme.
My 2c.
Michael
I couldn't agree more. However, there does not appear to be an alternative
way of doing this registration. Briefly, here is the problem I am
trying to solve.
* I have a base class (say) myBase.
* I expect other users of my library to derive objects from myBase.
* The application `creates' the derived objects as per the pattern above,
based on which ones the user wants as per a config file.
* So: if the user specifies an object that is not built, then the app
is going to
throw an exception and abort.
* The whole point of doing this is that the application is a
`framework' for the
user `to host his derived class'.
This approach permits me to keep the application and the `framework' code
agnostic to the user's derived classes.
I'd be more than happy to find a better way of achieving the
framework's agnosticism
to the derived classes, while providing the user to derive whatever
objects he likes.
When I solved this problem on .NET I was forced to run through all the
assemblies
to find the relevant objects and then use reflection to instantiate
them. That was even
uglier.
Thanks all!
--Sanatan
--
Sanatan Rai
3, Admirals Court,
30, Horselydown Lane,
London, SE1 2LJ.
+44-20-7403-2479.
___
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] many false positives in ctest error/warning reporting
Hi, On Saturday 21 May 2011 12:38:58 Alexander Neundorf wrote: On Thursday 19 May 2011, Matthias Kretz wrote: On Tuesday 10 May 2011 21:47:41 Alexander Neundorf wrote: Are you using cmake = 2.8 ? If so, there the switch CTEST_USE_LAUNCHERS. If this is set in your ctest- script, the output parsing works better. After I set CTEST_USE_LAUNCHERS (I didn't change anything else at the same time), all warnings and errors are suppressed. I.e. the dashboard sees 0 warnings and 0 errors on every build now. Which is clearly wrong. No idea, I never had such problems myself. Can you post the ctest script and the ctest settings file you are using ? I attached the four files, which are the most relevant (You can browse the whole repo at http://code.compeng.uni-frankfurt.de/projects/vc/repository). I start nightly runs with % ./Test_vc.sh Nightly The shell script gathers meta information and exports it via env vars to the test.cmake script. (One day I'd like to get rid of the wrapping shell script and do it all in the test.cmake script.) Regards, Matthias -- Matthias Kretz (Germany) http://kretzfamily.de/ test.cmake Description: Binary data Test_vc.sh Description: Binary data CTestCustom.cmake Description: Binary data CTestConfig.cmake Description: Binary data ___ 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] Newbie question: Static linking
On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan ___ 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] Newbie question: Static linking
On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. Michael ___ 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] Newbie question: Static linking
On 23 May 2011 13:38, Michael Wild them...@gmail.com wrote: On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. I guess this is getting to be off topic, but indeed the anonymous namespace trick is supposed to do exactly that. I am not trying to be difficult here---just that it is not clear to me that the solution to this problem is that straightforward. When all the code files are linked in one monolithic bloc, everything works correctly. It is when one starts dividing them into individual libraries that this problem occurs. I haven't seen a solution to this problem either in books or via google. --Sanatan ___ 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] Newbie question: Static linking
On 05/23/2011 03:25 PM, Sanatan Rai wrote: On 23 May 2011 13:38, Michael Wild them...@gmail.com wrote: On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. I guess this is getting to be off topic, but indeed the anonymous namespace trick is supposed to do exactly that. I am not trying to be difficult here---just that it is not clear to me that the solution to this problem is that straightforward. When all the code files are linked in one monolithic bloc, everything works correctly. It is when one starts dividing them into individual libraries that this problem occurs. I haven't seen a solution to this problem either in books or via google. --Sanatan The problem is, that when you link a static library to another binary (be it shared library or executable) only the *required* symbols are used, all others get discarded. Since nothing in your code actually references those global instances in the anonymous namespace (the linker doesn't care about that, BTW), they are ignored. Four solutions: 1. Only do monolithic builds. 2. Use shared libraries/DLLs 3. Use --whole-archive or similar and hack your way through MSVC (I did it once. It was ugly. Very ugly. See https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c. Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I replaced it with an explicit registration scheme now...) 4. Use an explicit registration scheme. For sanity's sake, go with 4. Michael ___ 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] Newbie question: Static linking
On May 23, 2011, at 10:11 AM, Michael Wild wrote: On 05/23/2011 03:25 PM, Sanatan Rai wrote: On 23 May 2011 13:38, Michael Wild them...@gmail.com wrote: On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. I guess this is getting to be off topic, but indeed the anonymous namespace trick is supposed to do exactly that. I am not trying to be difficult here---just that it is not clear to me that the solution to this problem is that straightforward. When all the code files are linked in one monolithic bloc, everything works correctly. It is when one starts dividing them into individual libraries that this problem occurs. I haven't seen a solution to this problem either in books or via google. --Sanatan The problem is, that when you link a static library to another binary (be it shared library or executable) only the *required* symbols are used, all others get discarded. Since nothing in your code actually references those global instances in the anonymous namespace (the linker doesn't care about that, BTW), they are ignored. Four solutions: 1. Only do monolithic builds. 2. Use shared libraries/DLLs 3. Use --whole-archive or similar and hack your way through MSVC (I did it once. It was ugly. Very ugly. See https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c. Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I replaced it with an explicit registration scheme now...) 4. Use an explicit registration scheme. For sanity's sake, go with 4. Michael I use 4 in my own code and everything just works and I have the same type of setup as the original poster. I have a few of my own concrete classes and the user can create new ones. They just have to register their own new classes in addition to calling the RegisterKnowFactories() method first. This ensures everything links correctly and is not that much to ask your programmers to do. I think VTK/ITK/ParaView may also use these types of design patterns. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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] Newbie question: Static linking
On 05/23/2011 04:40 PM, aaron.mead...@thomsonreuters.com wrote: -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Wild Sent: Monday, May 23, 2011 9:12 AM To: cmake@cmake.org Subject: Re: [CMake] Newbie question: Static linking On 05/23/2011 03:25 PM, Sanatan Rai wrote: On 23 May 2011 13:38, Michael Wild them...@gmail.com wrote: On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. I guess this is getting to be off topic, but indeed the anonymous namespace trick is supposed to do exactly that. I am not trying to be difficult here---just that it is not clear to me that the solution to this problem is that straightforward. When all the code files are linked in one monolithic bloc, everything works correctly. It is when one starts dividing them into individual libraries that this problem occurs. I haven't seen a solution to this problem either in books or via google. --Sanatan The problem is, that when you link a static library to another binary (be it shared library or executable) only the *required* symbols are used, all others get discarded. Since nothing in your code actually references those global instances in the anonymous namespace (the linker doesn't care about that, BTW), they are ignored. Four solutions: 1. Only do monolithic builds. 2. Use shared libraries/DLLs 3. Use --whole-archive or similar and hack your way through MSVC (I did it once. It was ugly. Very ugly. See https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef 791054a30c. Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I replaced it with an explicit registration scheme now...) 4. Use an explicit registration scheme. For sanity's sake, go with 4. Michael Couldn't you do: 5) Add references to the global instances inside something within the same copilational unit which you know will be imported. (Such as a static reference to the global instance inside a function you know will be called.) That, effectively, is an explicit registration scheme. Michael ___ 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] Newbie question: Static linking
-Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Wild Sent: Monday, May 23, 2011 9:12 AM To: cmake@cmake.org Subject: Re: [CMake] Newbie question: Static linking On 05/23/2011 03:25 PM, Sanatan Rai wrote: On 23 May 2011 13:38, Michael Wild them...@gmail.com wrote: On 05/23/2011 02:20 PM, Sanatan Rai wrote: On 23 May 2011 12:54, Michael Jackson mike.jack...@bluequartz.net wrote: You might want to take a look at the Factory design pattern. That's exactly what I use... --Sanatan Yes, but you are registering the concrete factories implicitly instead of explicitly, which is causing you the trouble you experience. Better have your user provide a function registering his/her classes explicitly. I guess this is getting to be off topic, but indeed the anonymous namespace trick is supposed to do exactly that. I am not trying to be difficult here---just that it is not clear to me that the solution to this problem is that straightforward. When all the code files are linked in one monolithic bloc, everything works correctly. It is when one starts dividing them into individual libraries that this problem occurs. I haven't seen a solution to this problem either in books or via google. --Sanatan The problem is, that when you link a static library to another binary (be it shared library or executable) only the *required* symbols are used, all others get discarded. Since nothing in your code actually references those global instances in the anonymous namespace (the linker doesn't care about that, BTW), they are ignored. Four solutions: 1. Only do monolithic builds. 2. Use shared libraries/DLLs 3. Use --whole-archive or similar and hack your way through MSVC (I did it once. It was ugly. Very ugly. See https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef 791054a30c. Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I replaced it with an explicit registration scheme now...) 4. Use an explicit registration scheme. For sanity's sake, go with 4. Michael Couldn't you do: 5) Add references to the global instances inside something within the same copilational unit which you know will be imported. (Such as a static reference to the global instance inside a function you know will be called.) Aaron 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. ___ 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] Newbie question: Static linking
On 23 May 2011 15:11, Michael Wild them...@gmail.com wrote:
Yes, but you are registering the concrete factories implicitly instead
of explicitly, which is causing you the trouble you experience.
Better have your user provide a function registering his/her classes
explicitly.
I guess this is getting to be off topic, but indeed the
anonymous namespace trick is supposed to do exactly that.
snipped
libraries that this problem occurs. I haven't seen a solution to this
problem either in books or via google.
--Sanatan
The problem is, that when you link a static library to another binary
(be it shared library or executable) only the *required* symbols are
used, all others get discarded. Since nothing in your code actually
references those global instances in the anonymous namespace (the linker
doesn't care about that, BTW), they are ignored.
Four solutions:
1. Only do monolithic builds.
2. Use shared libraries/DLLs
3. Use --whole-archive or similar and hack your way through MSVC (I did
it once. It was ugly. Very ugly. See
https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
replaced it with an explicit registration scheme now...)
4. Use an explicit registration scheme.
For sanity's sake, go with 4.
Ok: you've lost me here. Are you saying a trick like:
namespace {
helper1 *createHelper1() { return (new Helper1());}
const bool isRegistered =
factory::instance().registerHelper(helper1, createHelper1);
}
isn't explicit?
I could do the following: create a global object in the cpp, that
belongs to a type that would
do the registration. Would you regard this also as implicit?
The problem with either of these approaches is the same: if the code
lives in a separate library
that is loaded only when needed, then these registrations don't take
place. So the framework doesn't
know that the objects can be available.
Apologies for seeming obtuse but I don't follow what you mean by
`explicit registration' here.
--Sanatan
___
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] Newbie question: Static linking
On 05/23/2011 04:51 PM, Sanatan Rai wrote:
On 23 May 2011 15:11, Michael Wild them...@gmail.com wrote:
Yes, but you are registering the concrete factories implicitly instead
of explicitly, which is causing you the trouble you experience.
Better have your user provide a function registering his/her classes
explicitly.
I guess this is getting to be off topic, but indeed the
anonymous namespace trick is supposed to do exactly that.
snipped
libraries that this problem occurs. I haven't seen a solution to this
problem either in books or via google.
--Sanatan
The problem is, that when you link a static library to another binary
(be it shared library or executable) only the *required* symbols are
used, all others get discarded. Since nothing in your code actually
references those global instances in the anonymous namespace (the linker
doesn't care about that, BTW), they are ignored.
Four solutions:
1. Only do monolithic builds.
2. Use shared libraries/DLLs
3. Use --whole-archive or similar and hack your way through MSVC (I did
it once. It was ugly. Very ugly. See
https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c.
Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
replaced it with an explicit registration scheme now...)
4. Use an explicit registration scheme.
For sanity's sake, go with 4.
Ok: you've lost me here. Are you saying a trick like:
namespace {
helper1 *createHelper1() { return (new Helper1());}
const bool isRegistered =
factory::instance().registerHelper(helper1, createHelper1);
}
isn't explicit?
I could do the following: create a global object in the cpp, that
belongs to a type that would
do the registration. Would you regard this also as implicit?
The problem with either of these approaches is the same: if the code
lives in a separate library
that is loaded only when needed, then these registrations don't take
place. So the framework doesn't
know that the objects can be available.
Apologies for seeming obtuse but I don't follow what you mean by
`explicit registration' here.
--Sanatan
Everything that relies on static/global initialization to register
factories is an implicit scheme. An explicit scheme is where the
dependent code (e.g. the main() function) calls a function to do the
registration.
Michael
___
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] Newbie question: Static linking
On 23 May 2011 16:00, Michael Wild them...@gmail.com wrote: Everything that relies on static/global initialization to register factories is an implicit scheme. An explicit scheme is where the dependent code (e.g. the main() function) calls a function to do the registration. Ok, got you. However, would this not imply a monolithic build? How is main to know that an object of a type belonging to a base class of interest exists in linked library? As I mentioned earlier, I did this a little more explicitly in a .NET project in the following manner: * I had a factory object, whose job it was to hold creator functions for objects of classes derived from a base class of interest. * The factory was a singleton, and had a static method that could be called. The method loaded all linked assemblies, and picked out classes that were derived from the base class. * Then it explicitly registered the class with the factory. This seems to me to be a hybrid between implicit and explicit registration. The actual mechanics as one might imagine relied heavily on .NET reflection calls. One of the ugliest bits of code I have ever written. --Sanatan ___ 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] Newbie question: Static linking
On May 23, 2011, at 11:09 AM, Sanatan Rai wrote: On 23 May 2011 16:00, Michael Wild them...@gmail.com wrote: Everything that relies on static/global initialization to register factories is an implicit scheme. An explicit scheme is where the dependent code (e.g. the main() function) calls a function to do the registration. Ok, got you. However, would this not imply a monolithic build? How is main to know that an object of a type belonging to a base class of interest exists in linked library? As I mentioned earlier, I did this a little more explicitly in a .NET project in the following manner: * I had a factory object, whose job it was to hold creator functions for objects of classes derived from a base class of interest. * The factory was a singleton, and had a static method that could be called. The method loaded all linked assemblies, and picked out classes that were derived from the base class. * Then it explicitly registered the class with the factory. This seems to me to be a hybrid between implicit and explicit registration. The actual mechanics as one might imagine relied heavily on .NET reflection calls. One of the ugliest bits of code I have ever written. --Sanatan Take a look at http://scm.bluequartz.net/mxa/mxadatamodel/trees/master/Code/MXA/DataImport for an example of how I did this in one of my older projects. The code that ties this together is then in http://scm.bluequartz.net/mxa/mxadatamodel/blobs/master/Examples/DataImport/main.cpp This should short enough for you to follow along. I am not saying mine is the utopian example but it does work. Mike Jackson ___ 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] Newbie question: Static linking
On Mon, May 23, 2011 at 10:51 AM, Sanatan Rai sana...@gmail.com wrote:
On 23 May 2011 15:11, Michael Wild them...@gmail.com wrote:
Yes, but you are registering the concrete factories implicitly instead
of explicitly, which is causing you the trouble you experience.
Better have your user provide a function registering his/her classes
explicitly.
I guess this is getting to be off topic, but indeed the
anonymous namespace trick is supposed to do exactly that.
snipped
libraries that this problem occurs. I haven't seen a solution to this
problem either in books or via google.
--Sanatan
The problem is, that when you link a static library to another binary
(be it shared library or executable) only the *required* symbols are
used, all others get discarded. Since nothing in your code actually
references those global instances in the anonymous namespace (the linker
doesn't care about that, BTW), they are ignored.
Four solutions:
1. Only do monolithic builds.
2. Use shared libraries/DLLs
3. Use --whole-archive or similar and hack your way through MSVC (I did
it once. It was ugly. Very ugly. See
https://github.com/themiwi/cppcheck/tree/227378f763d50b005b7dd2167e2cef791054a30c
.
Especially lib/CMakeLists.txt and lib/generateStaticLinkFlags.cmake. I
replaced it with an explicit registration scheme now...)
4. Use an explicit registration scheme.
For sanity's sake, go with 4.
Ok: you've lost me here. Are you saying a trick like:
namespace {
helper1 *createHelper1() { return (new Helper1());}
const bool isRegistered =
factory::instance().registerHelper(helper1, createHelper1);
}
isn't explicit?
That's correct. It's not explicit. Because if nothing references the bool
variable isRegistered then the linker is free to (possibly) throw away
it's initialization because it's not referenced. This code may work with
some compilers; but it is not guaranteed to work.
I could do the following: create a global object in the cpp, that
belongs to a type that would
do the registration. Would you regard this also as implicit?
The problem with either of these approaches is the same: if the code
lives in a separate library
that is loaded only when needed, then these registrations don't take
place. So the framework doesn't
know that the objects can be available.
Apologies for seeming obtuse but I don't follow what you mean by
`explicit registration' here.
Explicit registration is having a method as mentioned earlier, something
like RegisterKnownFactories and then asking clients to make sure they call
that method first before calling anything that requires a factory to create
something.
HTH,
David
--Sanatan
___
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] Newbie question: Static linking
On 05/23/2011 05:09 PM, Sanatan Rai wrote: On 23 May 2011 16:00, Michael Wild them...@gmail.com wrote: Everything that relies on static/global initialization to register factories is an implicit scheme. An explicit scheme is where the dependent code (e.g. the main() function) calls a function to do the registration. Ok, got you. However, would this not imply a monolithic build? How is main to know that an object of a type belonging to a base class of interest exists in linked library? As I mentioned earlier, I did this a little more explicitly in a .NET project in the following manner: * I had a factory object, whose job it was to hold creator functions for objects of classes derived from a base class of interest. * The factory was a singleton, and had a static method that could be called. The method loaded all linked assemblies, and picked out classes that were derived from the base class. * Then it explicitly registered the class with the factory. This seems to me to be a hybrid between implicit and explicit registration. The actual mechanics as one might imagine relied heavily on .NET reflection calls. One of the ugliest bits of code I have ever written. --Sanatan If it is acceptable to have just one hook, just require your user to define a specific function, e.g. registerUserFactories which you then call. Otherwise it becomes more tricky. Michael ___ 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] [SOLVED] BundleUtilities with MinGW under Windows
You're right
To solve the problem I had to add the following paths to the environment to get
it to work:
.) C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE
.) C:\Windows\System32
set PATH=C:\Windows\System32;C:\Program Files (x86)\Microsoft Visual Studio
9.0\Common7\IDE;%PATH%
Can I set environment variables in CMake? I would like to add those paths to
the PATH if they aren't there
Best Regards and thanks for your help
NoRulez
-Ursprüngliche Nachricht-
Von: Clinton Stimpson [mailto:clin...@elemtech.com]
Gesendet: Montag, 23. Mai 2011 16:44
An: NoRulez
Betreff: Re: AW: [CMake] BundleUtilities with MinGW under Windows
I don't see how those changes to BundleUtilities make it work or not work for
you. I'm concerned it warns about dlls in system32.
So, it seems you have removed standard paths from your PATH environment
variable.
Clint
On Friday, May 20, 2011 04:04:18 pm you wrote:
So, I've a temporary solution/fix, but I don't know why this problem
occurs.
I commented the following lines, see the diff:
BundleUtilities.cmake:
714,718c714,718
if(external_prereqs)
# Found non-system/somehow-unacceptable prerequisites:
set(result 0)
set(info ${info} external prerequisites
found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n)
endif(external_prereqs)
---
#if(external_prereqs)
# # Found non-system/somehow-unacceptable prerequisites:
# set(result 0)
# set(info ${info} external prerequisites
found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n)
#endif(external_prereqs)
After this it works as expected, all files are packed:
QtCore4.dll
QtGui4.dll
QtTest.exe
libgcc_s_dw2-1.dll
mingwm10.dll
Uninstall.exe
The only messages I get, which won't work if the lines aren't commented out
are such as the followings:
warning: target 'COMDLG32.DLL' is not absolute...
warning: target 'COMDLG32.DLL' does not exist...
warning: target 'GDI32.dll' is not absolute...
warning: target 'GDI32.dll' does not exist...
warning: target 'IMM32.DLL' is not absolute...
warning: target 'IMM32.DLL' does not exist...
warning: target 'OLEAUT32.DLL' is not absolute...
warning: target 'OLEAUT32.DLL' does not exist...
warning: target 'SHELL32.DLL' is not absolute...
warning: target 'SHELL32.DLL' does not exist...
warning: target 'WINMM.DLL' is not absolute...
warning: target 'WINMM.DLL' does not exist...
warning: target 'KERNEL32.dll' is not absolute...
warning: target 'KERNEL32.dll' does not exist...
CPack Verbose:
warning: cannot resolve item 'KERNEL32.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'KERNEL32.dll' returning type 'other' -- possibly incorrect CPack Verbose:
warning: cannot resolve item 'msvcrt.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: info: non-absolute msvc file 'msvcrt.dll' returning type
'system' CPack Verbose:
warning: cannot resolve item 'ADVAPI32.DLL'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'ADVAPI32.DLL' returning type 'other' -- possibly incorrect CPack Verbose:
warning: cannot resolve item 'COMDLG32.DLL'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'COMDLG32.DLL' returning type 'other' -- possibly incorrect CPack Verbose:
warning: cannot resolve item 'GDI32.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file 'GDI32.dll'
returning type 'other' -- possibly incorrect .
.
.
.
-Ursprüngliche Nachricht-
Von: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] Im Auftrag
von NoRulez Gesendet: Freitag, 20. Mai 2011 22:57
An: 'Clinton Stimpson'; cmake@cmake.org
Betreff: Re: [CMake] BundleUtilities with MinGW under Windows
When I run the command I get the following message, but mingwm10.dll is
missing. Instead of mingwm10.dll the file msvcrt.dll is listed:
C:\Repository\Git\TestProject\builddumpbin /dependents QtTest.exe
C:\Repository\Git\TestProject\buildMicrosoft (R) COFF Binary File Dumper
Version 5.12.8078 Copyright (C) Microsoft Corp 1992-1998. All rights
reserved.
Dump of file QtTest.exe
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
QtCore4.dll
Re: [CMake] Newbie question: Static linking
On 05/23/2011 05:09 PM, Sanatan Rai wrote:
On 23 May 2011 16:00, Michael Wild them...@gmail.com wrote:
Everything that relies on static/global initialization to register
factories is an implicit scheme. An explicit scheme is where the
dependent code (e.g. the main() function) calls a function to do the
registration.
Ok, got you. However, would this not imply a monolithic build? How is
main to know that an object of a type belonging to a base class of interest
exists in linked library?
In order to further clarify things, look at the following project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GLOBALS CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_LIBRARY(helper STATIC helper.cxx)
ADD_EXECUTABLE(main main.cxx)
TARGET_LINK_LIBRARIES(main helper)
// main.cxx:
int main(void){return 0;}
// helper.cxx:
#include iostream
class helper {};
namespace {
bool registerhelper(const char *ident, helper *(*creator)())
{
std::cout ident = (void *)creator std::endl;
}
helper *helperCreator()
{
return (new helper());
}
const bool helperRegistered = registerhelper(helper, helperCreator);
}
If I'm not mistaken, this is roughly what you do in your project.
Although the main target is linked against libhelper.a, the object file
helper.cxx.o is dropped because none of its entities is referred to by
main.cxx, or in other words: Which reason the linker should have to
include helper.cxx.o in the final binary? To make helper.cxx.o be
included, a single reference from main.cxx usually suffices:
// helper.cxx:
#include iostream
int h; // -- For external reference.
class helper {};
namespace {
bool registerhelper(const char *ident, helper *(*creator)())
{
std::cout ident = (void *)creator std::endl;
}
helper *helperCreator()
{
return (new helper());
}
const bool helperRegistered = registerhelper(helper, helperCreator);
}
// main.cxx:
extern int h;
int h0 = h;
int main(void){return 0;}
Now, the entities from helper.cxx.o are included in the final binary,
i.e. you'll see the ident=... message. Of course, the same happens
when you include helper.cxx.o immediately in the main executable by
mentioning helper.cxx among main's source files, i.e. a monolithic
build. However, be aware that advanced linkers and, in particular,
optimising compiler back-ends may feel free to remove entities that
seem to be unnecessary for the program to run, as David has remarked
in the meantime.
Michael's advice to explicitly register your factory classes means that
there will be an external reference to the concerned object files, so
they'll be included and the registration will be done via the boolean
constants' initialisation, and that's what I'd advise, too. ATM, you
try to have some actions performed in your program without referring
to these actions by any means, and this simply does not work.
Besides, when using --[no-]whole-archive in order to force the linker
to include all of a static library's object files - be aware of the
already mentioned limitations and the fact that you will get *all*
object files, not just the ones you need - you might intersperse
these flags immediately in TARGET_LINK_LIBRARIES() without -L/-l:
target_link_libraries(myTarget
-Wl,--whole-archive helper1 helper2 -Wl,--no-whole-archive)
As I mentioned earlier, I did this a little more explicitly in a
.NET project in the following
manner:
* I had a factory object, whose job it was to hold creator functions
for objects of classes
derived from a base class of interest.
* The factory was a singleton, and had a static method that could be
called. The method loaded
all linked assemblies, and picked out classes that were derived
from the base class.
* Then it explicitly registered the class with the factory.
This seems to me to be a hybrid between implicit and explicit
registration. The actual mechanics
as one might imagine relied heavily on .NET reflection calls. One of
the ugliest bits of code I have
ever written.
If the object file holding the factory is placed in a static library,
and if there's no reference to any of this object file's entities from
anywhere, the above-noted approach would also fail on *nix, but you say
...a static method that could be called.: Calling this method *is* a
reference to the factory's object file from outside, so it would be
included in the final binary, and everything works fine.
In summary, this whole issue is not related to C++ or even to CMake,
but to the manner static libraries are handled: The linker - at least
the GNU one - picks out entire object files, or drops them if they are
not referred to. This is something one must keep in mind, particularly
when dealing with global objects for initialisation purposes. BTW, also
keep in mind that the order of initialisations, i.e. constructor calls,
among global objects is unspecified; this might become important when
such global objects refer to each
Re: [CMake] [SOLVED] BundleUtilities with MinGW under Windows
Yeah, when I tried with mingw, I had to add
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE
otherwise dumpbin.exe doesn't work and it complains about a missing dll.
Something like this might work for you to set those paths at install time, and
before the install() that uses BundleUtilities. But shouldn't system32
already be in your path?
install(CODE
if(WIN32)
set(ENV{PATH}
\C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\
C:\Windows\System32
\$ENV{PATH}
endif()
)
if you don't like the escaping of quotes and dollar signs, put it in a
separate file and use install(SCRIPT ..) instead.
Eventually, it might be nice to support mingw's objdump, then you can do this
without a Visual Studio installation.
Clint
On Monday, May 23, 2011 10:39:31 am NoRulez wrote:
You're right
To solve the problem I had to add the following paths to the environment to
get it to work:
.) C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE
.) C:\Windows\System32
set PATH=C:\Windows\System32;C:\Program Files (x86)\Microsoft Visual Studio
9.0\Common7\IDE;%PATH%
Can I set environment variables in CMake? I would like to add those paths
to the PATH if they aren't there
Best Regards and thanks for your help
NoRulez
-Ursprüngliche Nachricht-
Von: Clinton Stimpson [mailto:clin...@elemtech.com]
Gesendet: Montag, 23. Mai 2011 16:44
An: NoRulez
Betreff: Re: AW: [CMake] BundleUtilities with MinGW under Windows
I don't see how those changes to BundleUtilities make it work or not work
for you. I'm concerned it warns about dlls in system32.
So, it seems you have removed standard paths from your PATH environment
variable.
Clint
On Friday, May 20, 2011 04:04:18 pm you wrote:
So, I've a temporary solution/fix, but I don't know why this problem
occurs.
I commented the following lines, see the diff:
BundleUtilities.cmake:
714,718c714,718
if(external_prereqs)
# Found non-system/somehow-unacceptable prerequisites:
set(result 0)
set(info ${info} external prerequisites
found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n)
endif(external_prereqs)
---
#if(external_prereqs)
# # Found non-system/somehow-unacceptable prerequisites:
# set(result 0)
# set(info ${info} external prerequisites
found:\nf='${f}'\nexternal_prereqs='${external_prereqs}'\n)
#endif(external_prereqs)
After this it works as expected, all files are packed:
QtCore4.dll
QtGui4.dll
QtTest.exe
libgcc_s_dw2-1.dll
mingwm10.dll
Uninstall.exe
The only messages I get, which won't work if the lines aren't commented
out are such as the followings:
warning: target 'COMDLG32.DLL' is not absolute...
warning: target 'COMDLG32.DLL' does not exist...
warning: target 'GDI32.dll' is not absolute...
warning: target 'GDI32.dll' does not exist...
warning: target 'IMM32.DLL' is not absolute...
warning: target 'IMM32.DLL' does not exist...
warning: target 'OLEAUT32.DLL' is not absolute...
warning: target 'OLEAUT32.DLL' does not exist...
warning: target 'SHELL32.DLL' is not absolute...
warning: target 'SHELL32.DLL' does not exist...
warning: target 'WINMM.DLL' is not absolute...
warning: target 'WINMM.DLL' does not exist...
warning: target 'KERNEL32.dll' is not absolute...
warning: target 'KERNEL32.dll' does not exist...
CPack Verbose:
warning: cannot resolve item 'KERNEL32.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'KERNEL32.dll' returning type 'other' -- possibly incorrect CPack
Verbose: warning: cannot resolve item 'msvcrt.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: info: non-absolute msvc file 'msvcrt.dll' returning type
'system' CPack Verbose:
warning: cannot resolve item 'ADVAPI32.DLL'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'ADVAPI32.DLL' returning type 'other' -- possibly incorrect CPack
Verbose: warning: cannot resolve item 'COMDLG32.DLL'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
CPack Verbose: warning: gp_resolved_file_type non-absolute file
'COMDLG32.DLL' returning type 'other' -- possibly incorrect CPack
Verbose: warning: cannot resolve item 'GDI32.dll'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
Re: [CMake] Handle lib64 library on Linux
Hi Eric,
Thanks for your reply. I tried setting the
FIND_LIBRARY_USE_LIB64_PATHS property, but this did not resolve the
problem. I will read through the bug report you linked to. Below is
my CMakeLists.txt file. Could you let me know if you see any issues?
Thanks,
Sara
cmake_minimum_required(VERSION 2.6)
PROJECT(Geo)
FIND_PACKAGE(ITK)
IF(ITK_FOUND)
INCLUDE( ${USE_ITK_FILE} )
ENDIF(ITK_FOUND)
FIND_PACKAGE(VTK)
IF(VTK_FOUND)
INCLUDE( ${USE_VTK_FILE} )
ENDIF(VTK_FOUND)
ADD_EXECUTABLE(SubsampleVolume SubsampleVolume.cxx )
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
TARGET_LINK_LIBRARIES(SubsampleVolume
ITKNumerics ITKIO ITKBasicFilters vtkRendering vtkIO vtkWidgets
vtkHybrid)
On May 22, 2011, at 12:14 AM, Eric Noulard wrote:
2011/5/22 Sara Rolfe smro...@u.washington.edu:
The latest version of CMake, cmake-2.8.4-Linux-i386.tar.gz does not
looking
in /lib64 paths. Could you let me know which version of CMake you
are
referring to, that checks this path?
2.8.4 should definitely have this is the
FIND_LIBRARY_USE_LIB64_PATHS global property.
$ cmake --help-property FIND_LIBRARY_USE_LIB64_PATHS
FIND_LIBRARY_USE_LIB64_PATHS
Whether FIND_LIBRARY should automatically search lib64
directories.
FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the
FIND_LIBRARY command should automatically search the lib64
variant of
directories called lib in the search path when building 64-bit
binaries.
This should be automatically set unless you are on Debian.
However like I said before the multilib/lib64 issue is more complex
than that
so read the comments of the following bug report:
http://public.kitware.com/Bug/view.php?id=12037
and may be related bugs therein and you should find the needed
informations
including what works what does not.
That said may be you can give us a small precise example
(i.e. a strip down version of your CMakeLists.txt which exhibit the
issue)
of what is not working for you and we may give more precise answer.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] Newbie question: Static linking
On 23 May 2011 17:46, Michael Hertling mhertl...@online.de wrote:
On 05/23/2011 05:09 PM, Sanatan Rai wrote:
On 23 May 2011 16:00, Michael Wild them...@gmail.com wrote:
Everything that relies on static/global initialization to register
factories is an implicit scheme. An explicit scheme is where the
dependent code (e.g. the main() function) calls a function to do the
registration.
snipped
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GLOBALS CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_LIBRARY(helper STATIC helper.cxx)
ADD_EXECUTABLE(main main.cxx)
snipped
helper *helperCreator()
{
return (new helper());
}
const bool helperRegistered = registerhelper(helper, helperCreator);
}
If I'm not mistaken, this is roughly what you do in your project.
Indeed.
snipped
// helper.cxx:
#include iostream
int h; // -- For external reference.
class helper {};
namespace {
bool registerhelper(const char *ident, helper *(*creator)())
{
std::cout ident = (void *)creator std::endl;
}
helper *helperCreator()
{
return (new helper());
}
const bool helperRegistered = registerhelper(helper, helperCreator);
}
// main.cxx:
extern int h;
int h0 = h;
int main(void){return 0;}
Now, the entities from helper.cxx.o are included in the final binary,
i.e. you'll see the ident=... message. Of course, the same happens
when you include helper.cxx.o immediately in the main executable by
mentioning helper.cxx among main's source files, i.e. a monolithic
build. However, be aware that advanced linkers and, in particular,
optimising compiler back-ends may feel free to remove entities that
seem to be unnecessary for the program to run, as David has remarked
in the meantime.
Absolutely.
Michael's advice to explicitly register your factory classes means that
there will be an external reference to the concerned object files, so
they'll be included and the registration will be done via the boolean
constants' initialisation, and that's what I'd advise, too. ATM, you
try to have some actions performed in your program without referring
to these actions by any means, and this simply does not work.
Besides, when using --[no-]whole-archive in order to force the linker
to include all of a static library's object files - be aware of the
already mentioned limitations and the fact that you will get *all*
object files, not just the ones you need - you might intersperse
these flags immediately in TARGET_LINK_LIBRARIES() without -L/-l:
target_link_libraries(myTarget
-Wl,--whole-archive helper1 helper2 -Wl,--no-whole-archive)
Yup, interspersing these flags is the approach I am taking at the moment.
As I mentioned earlier, I did this a little more explicitly in a
.NET project in the following
manner:
* I had a factory object, whose job it was to hold creator functions
for objects of classes
derived from a base class of interest.
snipped
If the object file holding the factory is placed in a static library,
and if there's no reference to any of this object file's entities from
anywhere, the above-noted approach would also fail on *nix, but you say
...a static method that could be called.: Calling this method *is* a
reference to the factory's object file from outside, so it would be
included in the final binary, and everything works fine.
Quite.
In summary, this whole issue is not related to C++ or even to CMake,
but to the manner static libraries are handled: The linker - at least
the GNU one - picks out entire object files, or drops them if they are
not referred to. This is something one must keep in mind, particularly
when dealing with global objects for initialisation purposes. BTW, also
keep in mind that the order of initialisations, i.e. constructor calls,
among global objects is unspecified; this might become important when
such global objects refer to each other.
I do realise that it was off-topic, but people very kindly offered suggestions!
So one had to go on!
Many thanks to all for a careful and useful discussion.
Unfortunately, I am stuck with the paradigm of having to kludge loading an
entire library. For various reasons the one may not have a reference to
the hosted object in main, which must remain agnostic. Indeed, in my particular
line of business (finance), this happens to be a `standard' pattern.
Whether good or bad is a discussion that'd be too off topic...(though am happy
to continue the discussion off/on list if people are so inclined!).
--Sanatan
___
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] Handle lib64 library on Linux
2011/5/23 Sara Rolfe smro...@u.washington.edu:
Hi Eric,
Thanks for your reply. I tried setting the FIND_LIBRARY_USE_LIB64_PATHS
property, but this did not resolve the problem. I will read through the bug
report you linked to. Below is my CMakeLists.txt file. Could you let me
know if you see any issues?
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
should be set BEFORE any find_package.
However which 64bit lib is not found?
What is the symptom?
Thanks,
Sara
cmake_minimum_required(VERSION 2.6)
PROJECT(Geo)
FIND_PACKAGE(ITK)
IF(ITK_FOUND)
INCLUDE( ${USE_ITK_FILE} )
ENDIF(ITK_FOUND)
FIND_PACKAGE(VTK)
IF(VTK_FOUND)
INCLUDE( ${USE_VTK_FILE} )
ENDIF(VTK_FOUND)
ADD_EXECUTABLE(SubsampleVolume SubsampleVolume.cxx )
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
TARGET_LINK_LIBRARIES(SubsampleVolume
ITKNumerics ITKIO ITKBasicFilters vtkRendering vtkIO vtkWidgets
vtkHybrid)
On May 22, 2011, at 12:14 AM, Eric Noulard wrote:
2011/5/22 Sara Rolfe smro...@u.washington.edu:
The latest version of CMake, cmake-2.8.4-Linux-i386.tar.gz does not
looking
in /lib64 paths. Could you let me know which version of CMake you are
referring to, that checks this path?
2.8.4 should definitely have this is the
FIND_LIBRARY_USE_LIB64_PATHS global property.
$ cmake --help-property FIND_LIBRARY_USE_LIB64_PATHS
FIND_LIBRARY_USE_LIB64_PATHS
Whether FIND_LIBRARY should automatically search lib64 directories.
FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether the
FIND_LIBRARY command should automatically search the lib64 variant of
directories called lib in the search path when building 64-bit
binaries.
This should be automatically set unless you are on Debian.
However like I said before the multilib/lib64 issue is more complex than
that
so read the comments of the following bug report:
http://public.kitware.com/Bug/view.php?id=12037
and may be related bugs therein and you should find the needed
informations
including what works what does not.
That said may be you can give us a small precise example
(i.e. a strip down version of your CMakeLists.txt which exhibit the issue)
of what is not working for you and we may give more precise answer.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] Newbie question: Static linking
Sanatan Rai wrote: Unfortunately, I am stuck with the paradigm of having to kludge loading an entire library. For various reasons the one may not have a reference to the hosted object in main, which must remain agnostic. Indeed, in my particular line of business (finance), this happens to be a `standard' pattern. Whether good or bad is a discussion that'd be too off topic...(though am happy to continue the discussion off/on list if people are so inclined!). What about your application calling an initStaticLibs() function which is defined in an header. That header is written by CMake using FILE(WRITE ...) because CMake knows which libs are there and by this which init functions need to be called. They just have to be somehow related to the library name. Eike signature.asc Description: This is a digitally signed message part. ___ 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] Handle lib64 library on Linux
Hi Eric,
Thanks for pointing this out. I changed the order, but am still
getting the same error:
make[2]: *** No rule to make target `/usr/lib/libuuid.so', needed by
`SubsampleVolume'. Stop.
make[1]: *** [CMakeFiles/SubsampleVolume.dir/all] Error 2
make: *** [all] Error 2
The location of libuuid on my machine is: /usr/lib64/libuuid.so
Thanks,
Sara
2011/5/23 Sara Rolfe smro...@u.washington.edu:
Hi Eric,
Thanks for your reply. I tried setting the
FIND_LIBRARY_USE_LIB64_PATHS
property, but this did not resolve the problem. I will read
through the bug
report you linked to. Below is my CMakeLists.txt file. Could you
let me
know if you see any issues?
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
should be set BEFORE any find_package.
However which 64bit lib is not found?
What is the symptom?
Thanks,
Sara
cmake_minimum_required(VERSION 2.6)
PROJECT(Geo)
FIND_PACKAGE(ITK)
IF(ITK_FOUND)
INCLUDE( ${USE_ITK_FILE} )
ENDIF(ITK_FOUND)
FIND_PACKAGE(VTK)
IF(VTK_FOUND)
INCLUDE( ${USE_VTK_FILE} )
ENDIF(VTK_FOUND)
ADD_EXECUTABLE(SubsampleVolume SubsampleVolume.cxx )
set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS ON)
TARGET_LINK_LIBRARIES(SubsampleVolume
ITKNumerics ITKIO ITKBasicFilters vtkRendering vtkIO
vtkWidgets
vtkHybrid)
On May 22, 2011, at 12:14 AM, Eric Noulard wrote:
2011/5/22 Sara Rolfe smro...@u.washington.edu:
The latest version of CMake, cmake-2.8.4-Linux-i386.tar.gz does
not
looking
in /lib64 paths. Could you let me know which version of CMake
you are
referring to, that checks this path?
2.8.4 should definitely have this is the
FIND_LIBRARY_USE_LIB64_PATHS global property.
$ cmake --help-property FIND_LIBRARY_USE_LIB64_PATHS
FIND_LIBRARY_USE_LIB64_PATHS
Whether FIND_LIBRARY should automatically search lib64
directories.
FIND_LIBRARY_USE_LIB64_PATHS is a boolean specifying whether
the
FIND_LIBRARY command should automatically search the lib64
variant of
directories called lib in the search path when building 64-bit
binaries.
This should be automatically set unless you are on Debian.
However like I said before the multilib/lib64 issue is more
complex than
that
so read the comments of the following bug report:
http://public.kitware.com/Bug/view.php?id=12037
and may be related bugs therein and you should find the needed
informations
including what works what does not.
That said may be you can give us a small precise example
(i.e. a strip down version of your CMakeLists.txt which exhibit
the issue)
of what is not working for you and we may give more precise answer.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] Handle lib64 library on Linux
2011/5/23 Sara Rolfe smro...@u.washington.edu: Hi Eric, Thanks for pointing this out. I changed the order, but am still getting the same error: make[2]: *** No rule to make target `/usr/lib/libuuid.so', needed by `SubsampleVolume'. Stop. make[1]: *** [CMakeFiles/SubsampleVolume.dir/all] Error 2 make: *** [all] Error 2 The location of libuuid on my machine is: /usr/lib64/libuuid.so libuuid does not appear as a direct dependency of your SubsampleVolume target, you wrote: TARGET_LINK_LIBRARIES(SubsampleVolume ITKNumerics ITKIO ITKBasicFilters vtkRendering vtkIO vtkWidgets vtkHybrid) So my guess is that this dependency is indirect and comes from either ITK or VTK, which seems confirmed by http://www.vtk.org/Wiki/ITK_Configuring_and_Building_for_Ubuntu_Linux#uuid_.28dependency.29 Did you manage to create a VTK application with CMake before? May be you should ask on VTK mailing list http://www.vtk.org/VTK/help/mailing.html about your link trouble. PS: beware not to drop the mailling list address -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] How to use Qt Mobility with CMake
Hi, I didn't find a QT_USE_QTMOBILITY and/or QT_USE_QTVERSIT and other commands/macros/options. How can I use cmake for a project which is using the mobility api? Thanks in advance Best Regards NoRulez ___ 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] Handle lib64 library on Linux
Hi Eric, Yes, I believe it is a dependancy from ITK. I saw that wiki page and at the time did not have that library, so I installed it. I have used CMake to successfully create applications using both VTK and ITK on a 32-bit machine. This problem arose when I moved to a 64-bit machine. I've also posted to the ITK mailing list, but so far no one there has had any ideas. Thanks, Sara On May 23, 2011, at 2:11 PM, Eric Noulard wrote: 2011/5/23 Sara Rolfe smro...@u.washington.edu: Hi Eric, Thanks for pointing this out. I changed the order, but am still getting the same error: make[2]: *** No rule to make target `/usr/lib/libuuid.so', needed by `SubsampleVolume'. Stop. make[1]: *** [CMakeFiles/SubsampleVolume.dir/all] Error 2 make: *** [all] Error 2 The location of libuuid on my machine is: /usr/lib64/libuuid.so libuuid does not appear as a direct dependency of your SubsampleVolume target, you wrote: TARGET_LINK_LIBRARIES(SubsampleVolume ITKNumerics ITKIO ITKBasicFilters vtkRendering vtkIO vtkWidgets vtkHybrid) So my guess is that this dependency is indirect and comes from either ITK or VTK, which seems confirmed by http://www.vtk.org/Wiki/ITK_Configuring_and_Building_for_Ubuntu_Linux#uuid_.28dependency.29 Did you manage to create a VTK application with CMake before? May be you should ask on VTK mailing list http://www.vtk.org/VTK/help/mailing.html about your link trouble. PS: beware not to drop the mailling list address -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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 CMAKE_C_COMPILER CMAKE_CXX_COMPILER Deletes Cache?
Ran into this with CMake 2.8.4 on Linux -- though apparently not on my OS X machine, go figure. I had a nightly build shell script that as a matter of course set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER on the command line. I was getting mysteriously unnamed builds in our Dashboard. What I traced it down to: When I ran cmake in a batch that sets the compiler variables, cmake decided that the compilers had been changed and deleted the cache and reran itself. Unfortunately it also forgot BUILDNAME -- which I also set on the command line, and the BUILDNAME reverted to its default value (set in my top level CMakelists.txt) of UNKNOWN-build. So is there any way not to descend into this hell of deleted cache variables? ___ 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 CMAKE_C_COMPILER CMAKE_CXX_COMPILER Deletes Cache?
On Mon, May 23, 2011 at 5:37 PM, kent williams nkwmailingli...@gmail.comwrote: Ran into this with CMake 2.8.4 on Linux -- though apparently not on my OS X machine, go figure. I had a nightly build shell script that as a matter of course set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER on the command line. I was getting mysteriously unnamed builds in our Dashboard. What I traced it down to: When I ran cmake in a batch that sets the compiler variables, cmake decided that the compilers had been changed and deleted the cache and reran itself. Unfortunately it also forgot BUILDNAME -- which I also set on the command line, and the BUILDNAME reverted to its default value (set in my top level CMakelists.txt) of UNKNOWN-build. So is there any way not to descend into this hell of deleted cache variables? ___ 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 If you start with a clean build tree, there shouldn't be a problem. If you start with a non-clean build tree, be sure to use the same compiler used last time. Neither of those ways should descend into hell. If you prove me wrong, I will bring you a cold beer in hell. Also, I would recommend using the environment variables CC and CXX to set the compiler. CMake only even looks at those env vars if the compiler is not already cached in the first place. If you pass them in via -D args, then those -D args override what's in the cache... :-) David ___ 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] Newbie question: Static linking
On 05/23/2011 08:42 PM, Sanatan Rai wrote: On 23 May 2011 17:46, Michael Hertling mhertl...@online.de wrote: In summary, this whole issue is not related to C++ or even to CMake, but to the manner static libraries are handled: The linker - at least the GNU one - picks out entire object files, or drops them if they are not referred to. This is something one must keep in mind, particularly when dealing with global objects for initialisation purposes. BTW, also keep in mind that the order of initialisations, i.e. constructor calls, among global objects is unspecified; this might become important when such global objects refer to each other. I do realise that it was off-topic, but people very kindly offered suggestions! So one had to go on! Many thanks to all for a careful and useful discussion. Please don't get me wrong on this point: Far be it from me to criticise your concern as off-topic; on a build system's mailing list, it rather isn't, IMO. Instead, I just wanted to point out that this issue is not immediately related to CMake or C++ but to the implications of static libraries. Of course, we can frankly discuss it here, especially how to address it with the means of CMake. Unfortunately, I am stuck with the paradigm of having to kludge loading an entire library. For various reasons the one may not have a reference to the hosted object in main, which must remain agnostic. Indeed, in my particular line of business (finance), this happens to be a `standard' pattern. Whether good or bad is a discussion that'd be too off topic...(though am happy to continue the discussion off/on list if people are so inclined!). In this thread, you have spoken about loading a library, library loaded when needed and library loaded in memory, e.g., but static libraries aren't loaded in this sense; they're examined at link time, and that's it. May it be possible that shared libraries are what you actually want, i.e. is there any reason why the libraries in question must be static? Note that shared libraries don't have the limitations of static ones; say, they are not cherry-picked w.r.t. object files. If you really want to have actions performed at the program's startup without any explicit ado, you might take a look at GCC's constructor/ destructor attributes, but be aware that this is highly dependent on the underlying binary format and the corresponding development tools. Regards, Michael ___ 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-commits] CMake branch, next, updated. v2.8.4-1581-g1b2b8fc
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1b2b8fc57b21f514c43e36b735789be879a06926 (commit)
via 8bd3e51a1cff4785c1dbdab33dd8b2fc286c116a (commit)
via d7b376b3a734c2356a1e5138cf0ae52112612e0c (commit)
via ac5b999fffc88a1db3d4558e2dd6fd104cf2258a (commit)
from cdaac15fdc77082e4ebcccb6c2b3ca8feedd9b98 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1b2b8fc57b21f514c43e36b735789be879a06926
commit 1b2b8fc57b21f514c43e36b735789be879a06926
Merge: cdaac15 8bd3e51
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon May 23 10:40:51 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon May 23 10:40:51 2011 -0400
Merge topic 'absoft-fortran-compiler' into next
8bd3e51 Absoft: Enable FortranCInterface check in Fortran test
d7b376b Absoft: Detect implicit link libraries on Linux and Mac
ac5b999 Add Absoft Fortran compiler id and basic flags
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bd3e51a1cff4785c1dbdab33dd8b2fc286c116a
commit 8bd3e51a1cff4785c1dbdab33dd8b2fc286c116a
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 24 11:21:41 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri May 20 09:00:21 2011 -0400
Absoft: Enable FortranCInterface check in Fortran test
Exclude module symbol mangling because Absoft mangles with .in. so the
symbols cannot be referenced from C.
diff --git a/Tests/Fortran/CMakeLists.txt b/Tests/Fortran/CMakeLists.txt
index 04563ef..90598d6 100644
--- a/Tests/Fortran/CMakeLists.txt
+++ b/Tests/Fortran/CMakeLists.txt
@@ -34,7 +34,7 @@ function(test_fortran_c_interface_module)
FortranCInterface_VERIFY()
FortranCInterface_VERIFY(CXX)
if(CMAKE_Fortran_COMPILER_SUPPORTS_F90)
-if(NOT CMAKE_Fortran_COMPILER_ID MATCHES SunPro|MIPSpro|PathScale)
+if(NOT CMAKE_Fortran_COMPILER_ID MATCHES SunPro|MIPSpro|PathScale|Absoft)
set(module_expected 1)
endif()
if(FortranCInterface_MODULE_FOUND OR module_expected)
@@ -108,6 +108,9 @@ if((${CMAKE_Fortran_COMPILER_ID} MATCHES Intel)
)
set(COMPATABLE_COMPILERS TRUE)
endif()
+if(${CMAKE_Fortran_COMPILER_ID}:${CMAKE_C_COMPILER_ID} MATCHES Absoft:GNU)
+ set(COMPATABLE_COMPILERS TRUE)
+endif()
if(COMPATABLE_COMPILERS
OR (${CMAKE_Fortran_COMPILER_ID} MATCHES ${CMAKE_C_COMPILER_ID} ))
test_fortran_c_interface_module()
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7b376b3a734c2356a1e5138cf0ae52112612e0c
commit d7b376b3a734c2356a1e5138cf0ae52112612e0c
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 24 11:18:18 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri May 20 08:57:51 2011 -0400
Absoft: Detect implicit link libraries on Linux and Mac
Use the -X -v flag to the Absoft front-end to pass -v to the gcc it
invokes under the hood. Teach CMakeParseImplicitLinkInfo to exclude
linker version lines from consideration as link lines. Fix parsing of
Sun's linker search path option -Y... to avoid conflict with the Mac
linker option -Ynum.
diff --git a/Modules/CMakeParseImplicitLinkInfo.cmake
b/Modules/CMakeParseImplicitLinkInfo.cmake
index 5405bda..ecb20dc 100644
--- a/Modules/CMakeParseImplicitLinkInfo.cmake
+++ b/Modules/CMakeParseImplicitLinkInfo.cmake
@@ -29,11 +29,13 @@ function(CMAKE_PARSE_IMPLICIT_LINK_INFO text lib_var
dir_var log_var obj_regex)
# Construct a regex to match linker lines. It must match both the
# whole line and just the command (argv[0]).
set(linker_regex ^( *|.*[/\\])(${linker}|ld|collect2)[^/\\]*( |$))
+ set(linker_exclude_regex collect2 version )
set(log ${log} link line regex: [${linker_regex}]\n)
string(REGEX REPLACE \r?\n ; output_lines ${text})
foreach(line IN LISTS output_lines)
set(cmd)
-if(${line} MATCHES ${linker_regex})
+if(${line} MATCHES ${linker_regex} AND
+NOT ${line} MATCHES ${linker_exclude_regex})
if(UNIX)
separate_arguments(args UNIX_COMMAND ${line})
else()
@@ -64,8 +66,8 @@ function(CMAKE_PARSE_IMPLICIT_LINK_INFO text lib_var dir_var
log_var obj_regex)
# Object file full path.
list(APPEND implicit_libs_tmp ${arg})
set(log ${log}arg [${arg}] == obj [${arg}]\n)
-elseif(${arg} MATCHES ^-Y(P,)?)
- # Sun search path.
+elseif(${arg} MATCHES ^-Y(P,)?[^0-9])
+ # Sun search path ([^0-9] avoids conflict with Mac -Ynum).
string(REGEX REPLACE ^-Y(P,)? dirs ${arg})
string(REPLACE : ; dirs ${dirs})
list(APPEND
[Cmake-commits] CMake branch, next, updated. v2.8.4-1586-g93c531e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 93c531efd33ada607f1407aa273b08c689bad9bf (commit)
via 5cf4ff6e1fefe964f19e5f83e7ef68ca64bd2e05 (commit)
from 3bd2fbb8a9aa72b9a5063c2180136230b46c0903 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=93c531efd33ada607f1407aa273b08c689bad9bf
commit 93c531efd33ada607f1407aa273b08c689bad9bf
Merge: 3bd2fbb 5cf4ff6
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon May 23 13:23:12 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon May 23 13:23:12 2011 -0400
Merge topic 'doc-output_required_files' into next
5cf4ff6 Document status of output_required_files command (#12214)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cf4ff6e1fefe964f19e5f83e7ef68ca64bd2e05
commit 5cf4ff6e1fefe964f19e5f83e7ef68ca64bd2e05
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon May 23 13:21:15 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon May 23 13:21:15 2011 -0400
Document status of output_required_files command (#12214)
This command is barely functional and exists only for historical
reasons. State this in the documentation.
diff --git a/Source/cmOutputRequiredFilesCommand.h
b/Source/cmOutputRequiredFilesCommand.h
index 0da7724..6038472 100644
--- a/Source/cmOutputRequiredFilesCommand.h
+++ b/Source/cmOutputRequiredFilesCommand.h
@@ -47,8 +47,7 @@ public:
*/
virtual const char* GetTerseDocumentation()
{
-return
- Output a list of required source files for a specified source file.;
+return Deprecated. Approximate C preprocessor dependency scanning.;
}
/**
@@ -57,12 +56,22 @@ public:
virtual const char* GetFullDocumentation()
{
return
+ This command exists only because ancient CMake versions provided it.
+ CMake handles preprocessor dependency scanning automatically using a
+ more advanced scanner.\n
output_required_files(srcfile outputfile)\n
Outputs a list of all the source files that are required by the
specified srcfile. This list is written into outputfile. This is
similar to writing out the dependencies for srcfile except that it
jumps from .h files into .cxx, .c and .cpp files if possible.;
}
+
+ /** This command is kept for compatibility with older CMake versions. */
+ virtual bool IsDiscouraged()
+{
+return true;
+}
+
cmTypeMacro(cmOutputRequiredFilesCommand, cmCommand);
void ListDependencies(cmDependInformation const *info,
---
Summary of changes:
Source/cmOutputRequiredFilesCommand.h | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.4-1590-g6f70675
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 6f706757d6f3c429d099452ac695ba66d98b23d1 (commit)
via a6b52bd8ef82d015231b426ac2d0a1e84ee3a823 (commit)
from 89f8947caae0920b39798aeb3164e4f889e24465 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f706757d6f3c429d099452ac695ba66d98b23d1
commit 6f706757d6f3c429d099452ac695ba66d98b23d1
Merge: 89f8947 a6b52bd
Author: David Cole david.c...@kitware.com
AuthorDate: Mon May 23 18:03:22 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon May 23 18:03:22 2011 -0400
Merge topic 'fix-11925-vcxproj-filters-mismatch' into next
a6b52bd VS10: Write header-only files in correct xml element (#11925)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6b52bd8ef82d015231b426ac2d0a1e84ee3a823
commit a6b52bd8ef82d015231b426ac2d0a1e84ee3a823
Author: David Cole david.c...@kitware.com
AuthorDate: Mon May 23 17:30:23 2011 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon May 23 17:30:23 2011 -0400
VS10: Write header-only files in correct xml element (#11925)
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index b8fef25..6d2338e 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -455,7 +455,11 @@ void cmVisualStudio10TargetGenerator::WriteGroups()
{
lang = None;
}
-if(lang[0] == 'C')
+if(header)
+ {
+ headers.push_back(sf);
+ }
+else if(lang[0] == 'C')
{
clCompile.push_back(sf);
}
@@ -467,10 +471,6 @@ void cmVisualStudio10TargetGenerator::WriteGroups()
{
customBuild.push_back(sf);
}
-else if(header)
- {
- headers.push_back(sf);
- }
else if(ext == idl)
{
idls.push_back(sf);
---
Summary of changes:
Source/cmVisualStudio10TargetGenerator.cxx | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.4-435-g0c64fcd
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 0c64fcd3097c9aa0c0329cf8c33074aec1cc505e (commit) from cac769f3a7850ad46be660f2c4a1f6928bac488f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c64fcd3097c9aa0c0329cf8c33074aec1cc505e commit 0c64fcd3097c9aa0c0329cf8c33074aec1cc505e Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue May 24 00:01:04 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue May 24 00:12:11 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 54b4c86..2af01d2 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 05) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 23) +SET(KWSYS_DATE_STAMP_DAY 24) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
