Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
Nicolas Desprès wrote: I have to confess that I never called find_package() without REQUIRED, and I can't think about any use case right now. The most simple one is probably the system-or-bundled one: check if the system has a good version of some package, use the one bundled with the sources otherwise. Or just: build without some feature if a package is not availble. Eike signature.asc Description: This is a digitally signed message part. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On Thursday 09 June 2011, Nicolas Desprès wrote: On Wed, Jun 8, 2011 at 8:08 PM, Alexander Neundorf neund...@kde.org wrote: ... I can't think of any reason why somebody would want to use find_package(...without REQUIRED) instead of optional_find_package(). Can somebody else see a reason ? I have to confess that I never called find_package() without REQUIRED, and I can't think about any use case right now. E.g. in KDE many packages are optional, if they are not found, the program is built without the feature which that package would have provided. The same for many other projects. E.g. Qt too has a lot of switches at configure-time. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Wednesday 08 June 2011, Brad King wrote: On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc455125317 48ffb770cb1124798 -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. It's not that far yet. You can see current automoc without Qt here: https://projects.kde.org/projects/kdesupport/automoc/repository/show?rev=no-qt It is a standalone executable, and to create an executable with automoc you have to use one of the macros provided in Automoc4Config.cmake: https://projects.kde.org/projects/kdesupport/automoc/repository/revisions/no- qt/entry/Automoc4Config.cmake i.e. automoc4_add_library() or automoc4_add_executable(). This creates a custom target for the respective target, and writes a file which contains the list of course files, include dirs, etc. When integrating it in cmake, it could simply stay that way, or it could be integrated better :-) At cmake time it needs to know: -the list of source files -the target it belongs to With that, it can generat for buildtime -the list of source files -the include directories -the definitions -maybe the directory for the target in CMakefiles/ for helper files This information somehow then at buildtime needs to get into the automoc. Currently this is a plain text file. If integrated, it might make more sense to put that in a cmake script file, so we don't need extra parsing functions. From the interface for the user, it could be an AUTOMOC argument for add_executable/add_library(), or new macros qt[45]_add_executable/library() could be created. This can be done in C++ or cmake script, both should be ok. At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, and if found, execute moc to generate this include file. And we need to make sure it is at least flexible enough for future Qt/moc changes. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Thursday 09 June 2011, Alexander Neundorf wrote: ... At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, It does even more that that. Some comments from the implementation: // the program goes through all .cpp files to see which moc files are // included. It is not really interesting how the moc file is named, but what // file the moc is created from. Once a moc is included the same moc may not // be included in the _automoc.cpp file anymore. OTOH if there's a // header containing Q_OBJECT where no corresponding moc file is included // anywhere a moc_filename.cpp file is created and included in the // _automoc.cpp file. ... // If the moc include is of the moc_foo.cpp style we expect the Q_OBJECT class // declaration in a header file. // If the moc include is of the foo.moc style we need to look for a Q_OBJECT // macro in the current source file, if it contains the macro we generate the // moc file from the source file, else from the header. Which the moc-scanner still could do. The interface I talked about is basically to allow CMake to filter noise away from the scanners so they don't get called for things they don't care about at all. What the scanner later does with the files it get's passed is only his point. Eike ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
This wish comes mainly from packagers, not from the developers themselves.
I am sure packagers would be happy if they had one consistent way to disable
every package any cmake checks for with a standardized option.
This is a nice goal, but I do not think it is easy to do.
What if find_package(Foo) is called in more than one location with
different COMPONENT values? What if one is required and the other is
not? What if the FindFoo.cmake script calls find_package(Bar) and does
not require it but the project also does find_package(Bar) and does? I'm
sure there are more cases I haven't listed here.
The overall problem is that not all calls of find_package() are intended
to declare a dependency of the main project on a third party package.
In order to make such intention explicit you need to have a different
syntax, like a macro that handles it in a way that makes sense for a
given project. When projects start nesting inside one another I'm not
even sure it is a well-defined problem.
if (! mf-IsOn(DISABLE_FIND_PACKAGE_name)
{
cacheVars = getAllCacheVars();
doNormalFinding();
newCacheVars = getAllCacheVars();
addedCacheVars = newCacheVars - cacheVars;
FIND_PACKAGE_name_CACHE_VARS = addedCacheVars;
put FIND_PACKAGE_name_CACHE_VARS in the cache
}
else // it is disabled
{
get FIND_PACKAGE_name_CACHE_VARS from cache
remove all variables listed there from cache
set name_FOUND to FALSE
}
That kind of auto-cache-cleanup logic will be problematic in non-toy
cases. If two different find_package() calls lead transitively to
the same cache values then one could erase the other's results.
-Brad
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/9/2011 4:12 AM, Alexander Neundorf wrote: AFAIK depending on generated files via the #include does not work/is not reliable (that's why generated files need to be added to the target). For the Makefile generators, each target builds in three steps: (1) Generate all custom command outputs (2) Run implicit dependency scanning (#include) (3) Compile source files This ensures that any generated sources are available in time to be picked up as dependencies of the compilation step. However, this all depends on knowing at CMake time what custom command outputs will be needed and adding them to the target so they show up in step (1). -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On Thursday 09 June 2011, Brad King wrote:
On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
This wish comes mainly from packagers, not from the developers
themselves. I am sure packagers would be happy if they had one
consistent way to disable every package any cmake checks for with a
standardized option.
This is a nice goal, but I do not think it is easy to do.
What if find_package(Foo) is called in more than one location with
different COMPONENT values? What if one is required and the other is
not?
Now that you say it, we (cmake) have issues with this anyway.
Some people told me in Randa that they have problems with this.
Calling FindQt4 in some directory with components A and B, and in some other
directory with component C, and the second one doesn't do anything because the
first one has already set something to I am done already so the second one
doesn't do anything.
Maybe we have the same issue when somebody calls
find_package(Foo 2.0.0 NO_MODULE)
in some directory, and it finds eg. version 2.0,
and
find_package(Foo 3.0.0 NO_MODULE)
in some other directory ?
Foo_DIR (which is in the cache) has been already set then.
This could be also mixed with different components, which may are only
installed for one of the two versions...
Maybe, if Foo is disabled, this could be interpreted as the user wants to be
independent from Foo, regardless of components etc., i.e. a quite global off-
switch.
I have to think a bit more about this.
What if the FindFoo.cmake script calls find_package(Bar) and does
not require it but the project also does find_package(Bar) and does? I'm
sure there are more cases I haven't listed here.
I think this can be handled.
find_package() should error out in this case, because Bar was required but it
was disabled.
Maybe this option to disable a find_package() could even be provided for all
find_package() calls, and for each REQUIRED one it will cause an error. This
would create a bunch of unusable options, but would be very consistent ;-)
The overall problem is that not all calls of find_package() are intended
to declare a dependency of the main project on a third party package.
In order to make such intention explicit you need to have a different
syntax, like a macro that handles it in a way that makes sense for a
given project. When projects start nesting inside one another I'm not
even sure it is a well-defined problem.
if (! mf-IsOn(DISABLE_FIND_PACKAGE_name)
{
cacheVars = getAllCacheVars();
doNormalFinding();
newCacheVars = getAllCacheVars();
addedCacheVars = newCacheVars - cacheVars;
FIND_PACKAGE_name_CACHE_VARS = addedCacheVars;
put FIND_PACKAGE_name_CACHE_VARS in the cache
}
else // it is disabled
{
get FIND_PACKAGE_name_CACHE_VARS from cache
remove all variables listed there from cache
set name_FOUND to FALSE
}
That kind of auto-cache-cleanup logic will be problematic in non-toy
cases. If two different find_package() calls lead transitively to
the same cache values then one could erase the other's results.
Are you sure ?
Let's say I have a project which uses PNG and ZLIB.
Assume I disable PNG (which finds ZLIB).
If PNG is searched first, both PNG and ZLIB variables are remved from the
cache. After this, when ZLIB is searched, it will search again, and the
results will end up in the cache.
The other way round, if I disable ZLIB, PNG will not be found, which is ok,
since this would have dragged in ZLIB.
Or maybe not actually remove them from the cache, but set the normal
variables to NOTFOUND ?
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/9/2011 8:47 AM, Alexander Neundorf wrote: So, if I would create a dummy foo.automoc file from automoc, and added this to the target, this would make sure that any files created as side-effects of this custom command would already exist when any source files are compiled ? Yes. I cannot say off the top of my head how that would work for the non-Makefile generators though. But this still means that custom commands cannot be triggered via the implicit dependency scanning, right ? Custom commands will not be drawn into a target by CMake if the only reference to their output is implicit in source file content. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument OPTIONAL to find_package() and add_subdirectory
On Thu, Jun 9, 2011 at 9:19 AM, Brad King brad.k...@kitware.com wrote: On 6/9/2011 8:50 AM, Alexander Neundorf wrote: What if the FindFoo.cmake script calls find_package(Bar) and does not require it but the project also does find_package(Bar) and does? I'm sure there are more cases I haven't listed here. I think this can be handled. find_package() should error out in this case, because Bar was required but it was disabled. Maybe this option to disable a find_package() could even be provided for all find_package() calls, and for each REQUIRED one it will cause an error. This would create a bunch of unusable options, but would be very consistent ;-) Okay. However, the option does not need to be provided as a gui-settable value for packagers to be able to disable things from build scripts. The command could honor the value if it is present but not advertise it. I think (as a former packager) that this would certainly go a long way to addressing the issue for packages. If the packager passes in --disable-find=Qt4 (or whatever command line syntax you use to expose) then all calls to find_package(Qt4) fail, and you just made CMake easier for packagers to use with little effort for developers in changing their scripts. Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Thursday, June 09, 2011 01:23:09 am Alexander Neundorf wrote: On Wednesday 08 June 2011, Brad King wrote: On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The two things are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.gita=commith=78fdba1e2d96bc4551253 17 48ffb770cb1124798 -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. It's not that far yet. You can see current automoc without Qt here: https://projects.kde.org/projects/kdesupport/automoc/repository/show?rev=no -qt It is a standalone executable, and to create an executable with automoc you have to use one of the macros provided in Automoc4Config.cmake: https://projects.kde.org/projects/kdesupport/automoc/repository/revisions/n o- qt/entry/Automoc4Config.cmake i.e. automoc4_add_library() or automoc4_add_executable(). This creates a custom target for the respective target, and writes a file which contains the list of course files, include dirs, etc. When integrating it in cmake, it could simply stay that way, or it could be integrated better :-) At cmake time it needs to know: -the list of source files -the target it belongs to With that, it can generat for buildtime -the list of source files -the include directories -the definitions -maybe the directory for the target in CMakefiles/ for helper files This information somehow then at buildtime needs to get into the automoc. Currently this is a plain text file. If integrated, it might make more sense to put that in a cmake script file, so we don't need extra parsing functions. From the interface for the user, it could be an AUTOMOC argument for add_executable/add_library(), or new macros qt[45]_add_executable/library() could be created. I'd like to see us go towards qt_* instead of having qt[45]_*. This can be done in C++ or cmake script, both should be ok. At build time, the logic is complex enough and it also has to be really fast so that this should IMO be done in the C++. It could either be a -E automoc infofile option, or a -P CMakeAutomoc.cmake script, which then calls a new automoc() function. This then needs to go through the list of source files, and if the file is newer than the associated stamp-file or if no stamp-file exists, it needs to parse the source file for a #include-moc statement, and if found, execute moc to generate this include file. And we need to make sure it is at least flexible enough for future Qt/moc changes. I'm just curious if trying to put automoc in Qt has been pursued, and maybe changing qmake to use automoc. It seems that would guarantee maintenance/compatibility for future versions of Qt. And if a future version of Qt could be compiled using CMake, having automoc on the Qt side would fit with having Qt-config.cmake and macros. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
