Re: [CMake] Code and API review request for Qt5 CMake files
On 02/26/2012 11:24 AM, Alexander Neundorf wrote: > On Sunday 26 February 2012, Michael Hertling wrote: >> On 02/25/2012 09:43 AM, Alexander Neundorf wrote: >>> On Friday 24 February 2012, Michael Hertling wrote: On 02/24/2012 03:34 PM, Stephen Kelly wrote: >>> ... >>> >> [...] (that is, find_package(Qt5 REQUIRED >> Gui Xml) might not find QtXml, but Qt5_FOUND would still be true if >> the Qt5Config file is found, whether the component is or not), [...] No: FIND_PACKAGE(Qt5 REQUIRED ...) is expected to bail out if any of the required components aren't found, so the value of the Qt5_FOUND variable doesn't matter in this case. BTW, note that FIND_PACKAGE() must not bail out if a component which the user hasn't requested is not found, regardless of the REQUIRED flag, unless the component is an immediate or mediate prerequisite of a required one. Regarding Qt5_FOUND, FIND_PACKAGE(Qt5 COMPONENTS ...), i.e. without REQUIRED, is more interesting, see [4]. In short: Qt5_FOUND indicates if Qt5 is basically present but says nothing about any component; the user must refer to the component-specific FOUND variables, and those >>> must even be protected by the package-specific one: >>> Ah, yes, I remember this discussion. >>> I'd sum up the results as follows: >>> >>> * Config-mode should behave the same way as Module-mode with regard to >>> COMPONENTS (I think this still needs changes in the find_package() >>> implementation) >> >> Which changes do you have in mind? AFAIK, config files and find modules >> can perfectly behave the same - provided they're implemented correctly. > > I think currently cmFindPackage.cxx in Config mode doesn't evaluate the per > component variables at all to decide whether the package has been found or > not, which may be required for the next point: > >>> * if REQUIRED is used, find_package(Foo COMPONENTS A B C) must only >>> succeed if all listed components have been found >> >> Perhaps, we can also include components which are immediate or mediate >> prerequisites of the listed ones. The REQUIRED flag should ensure that >> anything necessary to use the listed components is actually available. > > Yes. > >>> * if REQUIRED is not used, we still have two opinions: >>> >>> 1.) FOO_FOUND should be the major sign whether everything I wanted has >>> been found or not. I.e. it is only set to TRUE if all listed components >>> have been found. To check whether some of the components have been >>> found, i.e. if FOO_FOUND==FALSE, I can check the per-component _FOUND >>> variables. The reasoning here is "I want to use some parts of a big >>> package, if they all are found, then I can use it, otherwise I can't use >>> the package at all" >> >> If FOO_FOUND==FALSE and FIND_PACKAGE() did load a config file, none of >> the per-component _FOUND variables has received a definite value, i.e. >> you'd refer to the values they already had before the invocation of >> FIND_PACKAGE(). > > Yes. But other resulting variables are also not reset by find_package() in > case of failure. So I wouldn't see this a problem. The fact that other variables remain untouched as well in this case doesn't make things better; you'd still query variables which are to be provided by the config file but have not been assigned a definite value by the latter. IMO, that's bad style, makes the configuration unneccessarily vulnerable and means asking for trouble in the long term. BTW, if FOO was a single-component package, one wouldn't use any of its typical variables for any purpose after FIND_PACKAGE() returned with FOO_FOUND==FALSE. Multi- and single-component packages should behave the same in this regard, as well as find modules and config files. FOO_FOUND's only consistent interpretation w.r.t. this is: FOO_FOUND==FALSE --> Hands off, don't use the package in any way; in particular, don't refer to any of the package's variables. >>> 2.) FOO_FOUND should only indicate that at least something of Foo has >>> been found. To check which modules have been found, i.e. if >>> FOO_FOUND==TRUE, I must check the per-component _FOUND variables. >>> The logic here is "I want to use some parts of a big package, and I can >>> use them independently from each other". >>> >>> Both make sense. >>> I'd prefer the first one. >> >> Presumably, you're not surprised that I move for the second. ;-) >> One of my favorite points for the latter is the following use case: >> >> Suppose there's a multi-component package FOO which provides some >> required components and some optional ones. The user has three >> distinct possibilities how those components can be requested: >> >> (A) Request all of them with the REQUIRED flag: Bad, a missing optional >> component would terminate the configuration although all is well. > > I would expect that if I don't specify any (subset of) components, it will > search for all, FOO_FOUND is set to TRUE if a "sufficient" subset
Re: [CMake] Cpack Nsis not installing libraries
2012/2/27 Mauricio Klein :
> Hello everybody!
>
> I'm creating a NSIS package using CPack to install my software.
>
> The code is compilled using Visual Studio 9, and the compilation + packing
> is working well.
>
> But, once i install the software using the generated NSIS package, the
> program doesn't start because NSIS did't installed the required libraries.
>
> The strange is that in my CMakeLists.txt, i tell that my binary requires
> these libraries.
>
> The libraries are:
> * OpenSSL
> * Pthreads
> (both found using find macros)
>
>
> The piece of configuration that defines these relashionship is showed
> bellow:
> -
> find_package(Pthreads REQUIRED)
> find_package(OpenSSL REQUIRED)
>
> include_directories(${OPENSSL_INCLUDE_DIR})
> include_directories(${PTHREADS_INCLUDE_DIR})
>
> install(TARGETS MyBin DESTINATION "MyBin1-0/bin")
> install(TARGETS ${PTHREADS} DESTINATION "MyBin1-0/bin")
> install(TARGETS ${OPENSSL} DESTINATION "MyBin1-0/bin")
${PTHREADS} and ${OPENSSL} seems wrong
usually those are:
${PTHREADS_LIBRARIES}
${OPENSSL_LIBRARIES}
moreover you cannot use install(TARGETS ) for those
because they are not TARGET unless you somehow define
them as IMPORTED library.
Usually "third party" libs (those which are not built in your project)
are not installed because they may be found on the host where
your software is installed already.
If you are interested in creating "autonomous" bundle
have a look at the BundleUtilities module.
> The "MyBin" binary is installed well, but the libraries of Pthreads and
> OpenSSL not!
>
> Any hint??
>
> Thanks in advance for your attention, and any help is very welcome!
May be you can tell us which version of CMake you are using
and which system you are targeting (Windows, Linux, MacOS Xetc...)
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.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] smarter shortcuts with NSIS
On 02/27/2012 05:51 PM, Eric Noulard wrote: 2012/2/27 John Drescher: Ah yes you're right, last time I checked I didn't see them.. Anyway my extra_commands don't appear anywhere in the nsi file, is that normal? No i'ts not. Did you set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ...) BEFORE Actually I didn't.. Some time ago it was failing when including after, so I moved all the includes on top. I'll change it again tomorrow then.. include(CPack) ? The process is relatively simple. 0) Your CPACK_xxx vars are set and processed by the inclusion of CPack.cmake (the include(CPack) of your CMakeLists.txt) 1) CPack NSIS generator "configures" the NSIS.template.in file by replacing occurences of CPACK_NSIS_... specific vars in there. 2) makensis is launched using the generated project.nsi CPack private installation of your project in a _CPackPackage subdir is done somewhere between 0) and 1). You need awkward extra escape in CPACK_NSIS_xxx because of the double CMake script processing 0) and 1). Is it clearer? Ok now is clear thanks -- 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] smarter shortcuts with NSIS
2012/2/27 John Drescher : >> Ah yes you're right, last time I checked I didn't see them.. >> Anyway my extra_commands don't appear anywhere in the nsi file, is that >> normal? No i'ts not. Did you set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ...) BEFORE include(CPack) ? The process is relatively simple. 0) Your CPACK_xxx vars are set and processed by the inclusion of CPack.cmake (the include(CPack) of your CMakeLists.txt) 1) CPack NSIS generator "configures" the NSIS.template.in file by replacing occurences of CPACK_NSIS_... specific vars in there. 2) makensis is launched using the generated project.nsi CPack private installation of your project in a _CPackPackage subdir is done somewhere between 0) and 1). You need awkward extra escape in CPACK_NSIS_xxx because of the double CMake script processing 0) and 1). Is it clearer? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.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] smarter shortcuts with NSIS
> Ah yes you're right, last time I checked I didn't see them.. > Anyway my extra_commands don't appear anywhere in the nsi file, is that > normal? I can't help with that part. I do add components also executables with shortcuts for my executables by setting the CPACK_PACKAGE_EXECUTABLES variable. However I never mess with changing the installation folders or creating shortcuts directly. -- John M. Drescher -- 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] smarter shortcuts with NSIS
On 02/27/2012 04:52 PM, John Drescher wrote: By the way, how do I see the actual paths NSI configuration that generates the final exe? It seems that if NSIS works the file used get all removed.. It does not get removed for me using Visual Studio 2010. All of the NSIS stuff exists in a _CPack_Packages folder inside of the build tree. John Ah yes you're right, last time I checked I didn't see them.. Anyway my extra_commands don't appear anywhere in the nsi file, is that normal? -- 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] smarter shortcuts with NSIS
> By the way, how do I see the actual paths NSI configuration that generates > the final exe? > It seems that if NSIS works the file used get all removed.. > It does not get removed for me using Visual Studio 2010. All of the NSIS stuff exists in a _CPack_Packages folder inside of the build tree. John -- 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] smarter shortcuts with NSIS
On 02/27/2012 03:34 PM, Andrea Crotti wrote:
My brain is almost going to explode, so before it does maybe someone
can help..
I have a cpack with NSIS working installer, which just copies a
directory.
In that directory there is a file run.exe, which needs to take an
argument to run correctly.
Now that argument is a path which is only known at install-time, via
asking to the user.
So what I would like to do is to:
1. get that path into a variable
2. stick it into the arguments of a shortcut file on the windows machine
I found something like this on stackoverflow:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "
CreateShortCut \\\"$DESKTOP${PROJECT_NAME}.lnk\\\"
\\\"$INSTDIRbuilt_eggrun.exe\\\" \"c:\python25\pythonw.exe\"
")
But I have some trouble understand in general, how is this command
processed?
First the cmake variables are substituted and then it's simply run?
And any advice on how to get the variable with the path?
Thanks,
Andrea
This is the first attempt:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "
PageEx directory
DirVar PythonDir
PageExEnd
CreateShortCut \\\"$DESKTOP${PROJECT_NAME}.lnk\\\"
\\\"$INSTDIRbuilt_eggrun.exe\\\" \"$PythonDir\\pythonw.exe\"
\"\" \"\" \".$INSTDIR\" \"Run project ${PROJECT_NAME}\"
")
but I don't get any page asking me for the destination directory, and no
shortcut is created..
By the way, how do I see the actual paths NSI configuration that
generates the final exe?
It seems that if NSIS works the file used get all removed..
--
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] smarter shortcuts with NSIS
My brain is almost going to explode, so before it does maybe someone can
help..
I have a cpack with NSIS working installer, which just copies a directory.
In that directory there is a file run.exe, which needs to take an
argument to run correctly.
Now that argument is a path which is only known at install-time, via
asking to the user.
So what I would like to do is to:
1. get that path into a variable
2. stick it into the arguments of a shortcut file on the windows machine
I found something like this on stackoverflow:
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "
CreateShortCut \\\"$DESKTOP${PROJECT_NAME}.lnk\\\"
\\\"$INSTDIRbuilt_eggrun.exe\\\" \"c:\python25\pythonw.exe\"
")
But I have some trouble understand in general, how is this command
processed?
First the cmake variables are substituted and then it's simply run?
And any advice on how to get the variable with the path?
Thanks,
Andrea
--
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] add_executable and extension of source file
Thanks Michael
The behaviour I was asking about is resolved. At some point in my
CMakeFiles.txt, it didn't work for my user on MacOSX, but apparently it does
work now, so I (or he) must have had another mistake in the files earlier
on. But you have made some helpful suggestions, so my comments are below
> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> Behalf Of Michael Hertling
> Sent: 24 February 2012 22:15
> To: cmake@cmake.org
> Subject: Re: [CMake] add_executable and extension of source file
>
> On 02/24/2012 06:16 PM, Kris Thielemans wrote:
> > Hi
> >
> > I have a project where I have C++ and C source files. I'm adding
> executables
> > for this (via macros) like this
> >
> > foreach(executable ${SOURCES})
> >add_executable(${executable} ${executable} )
> >target_link_libraries(${executable} ${STIR_LIBRARIES})
> > endforeach()
> >
> > where ${SOURCES} is a list of sources WITHOUT extension, e.g.
> >
> > set( SOURCES abs_image src2)
> >
> > This relies on the fact that cmake should find .cxx and .c etc source
files
> > for add_executable. At least, I think it should (I found this some
tutorial,
> > e.g.
> > http://www-
> flc.desy.de/ldcoptimization/documents/talks/CMake_Tutorial.pdf),
> > but the doc for add_executable does not seem to mention this behaviour.
> >
> > My current CMake files work fine on Windows and Linux, but I now have a
> > MacOSX user who says that it fails. He's running cmake 2.8.7 and when I
> > inspect that linking command, it looks like (slightly edited for
brevity)
> >
> > /usr/bin/c++ -O3 -DNDEBUG -ffast-math -Wl,-search_paths_first
> > -Wl,-headerpad_max_install_names
> > -o abs_image a ../buildblock/libbuildblock.a
> >
> > That is, clearly the abs_image.o file is missing on this command line.
> >
> > Maybe this "adding a list of known extensions" feature is no longer
> > supported? Or is the list of known extensions platform specific? (that
> would
> > be bad)
>
> The gcc manpage states:
>
>
> For any given input file, the file name suffix determines what kind of
> compilation is done:
>
> file.c
> C source code which must be preprocessed.
> ...
> other
> An object file to be fed straight into linking. Any file name with
> no recognized suffix is treated this way.
> ...
> -c Compile or assemble the source files, but do not link. [...]
>
> Unrecognized input files, not requiring compilation or assembly,
> are ignored.
>
>
> Thus, AFAICS, CMake handles the extension-less sources correctly, but
> gcc freaks out: No extension --> ignore when compiling --> no object
> file. IMO, it's a quite bad idea to provide source files without a
> proper suffix. However, see gcc's -x switch.
>
Seems that I didn't explain myself properly. My files do have an extension,
and I want this to be passed on to the compiler. It seems that CMake
actually does this for add_executable (i.e. you can do "add_executable
my_file my_file" and it will check if there's a my_file.c etc). (As I
mentioned above, this does after all seem to work on MacOSX as well).
However, as it isn't documented clearly, and not entirely safe anyway, I
think I'll replace it with your suggestion below.
> > I guess I will have to set my SOURCE files with the extension, and then
> > strip the extension for the executable-name. maybe with something like
> >
> > foreach(src ${SOURCES})
> > STRING(REPLACE \(.*\)\..* \1 executable ${src})
> > add_executable(${executable} ${src} )
> > ...
> > endforeach()
>
> SET(SOURCES abs_image.cxx src2.c)
> ...
> FOREACH(i IN LISTS SOURCES)
> GET_FILENAME_COMPONENT(j ${i} NAME_WE)
> ADD_EXECUTABLE(${j} ${i})
> ENDFOREACH()
>
This sounds good to me! Thanks
> > or alternatively find the source file
> >
> > foreach(executable ${SOURCES})
> >FILE(GLOB src "*.cxx" "*.c")
> > add_executable(${executable} ${src} )
> >target_link_libraries(${executable} ${STIR_LIBRARIES})
> > endforeach()
>
> Do not use FILE(GLOB ...) in a CMakeLists.txt since this makes the
> latter unaware of additions/removals/renamings among your sources.
> You will most certainly miss a necessary reconfiguration one day.
>
Agreed. I suppose if I don't add the extension, something like the above is
effectively what cmake is doing. But passing extensions to specify the
complete filename seems a better way of doing things.
Thanks again!
Kris
--
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] Partial 3rd-party library management
> In order to maximize our ability to rebuild an exact copy of a previous
> revision, our repository carries copies of numerous 3rd party libraries.
>
> However, in most of their cases we are fairly selective about which
> elements we build.
>
> Downside: "make clean && make" winds up rebuilding all the damn libraries
> :)
>
> At the same time, we have a large number of customized project-wide
> customizations, depending on which client / product version we're
> building for. So, when we are building - as opposed to developing - we
> need the ability to easily perform a full rebuild, including possibly
> the libraries.
>
> For a nominal development "clean" build, upto 70% of the build time is
> spent building 3rd party libraries.
>
> Right now - for simplicity - we actually assemble the 3rd libraries from
> the top level CMakeLists.txt directly (ok, simplicity and a failure on
> my part to work out how to express that "libraryXXX.a" is an output of
> "subfolderX").
>
> /The problem/
>
> Something like a source-control revert can sometimes put /our/ part of
> the code base into a state that requires a clean. However, we don't want
> to cause the libraries to rebuild /except/ when someone changes
> compilation flags or forces a rebuild of the libraries somehow else
> (e.g. a "cleanall" target).
>
> Is there a way to do this with cmake? Or is this problem only because I
> haven't (yet) split these libraries into their own CMakeLists files?
>
> The simplest and therefore easiest complete example I have is:
>
> 8x --- snip --- x8
>add_library(ircclient SHARED libircclient/src/libircclient.c)
>set_property(TARGET ircclient PROPERTY COMPILE_DEFINITIONS
> IN_BUILDING_LIBIRC)
>link_directories( ${Project_BINARY_DIR}/ircclient )
> 8x --- snip --- x8
No, you don't want this link_directories() here. You later do
target_link_libraries(something ircclient), which will make CMake fiddle
out the link directory and it's ordering on it's own. Explicitely
specifying link_directories() is almost always wrong and just adding pain.
My way to solve your general problem: have one top level CMakeLists.txt
that just collects the various libraries and then decend into your source
tree:
add_subdirectory(foreign_libA)
add_subdirectory(foreign_libB)
add_subdirectory(our_stuff)
If you want to get rid of your stuff:
cd ~/buildtree/our_stuff && make clean && make
Eike
--
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
