Re: [CMake] FindModules.cmake quality + Kitware proposition
I'll add to it that all the Find Modules should be able to support projects
that have their own builds of a library. Some Find Modules (e.g FindBoost)
works generally well and supports HINTS and PATHS; but other (FindCURL) do not.
For me, this means that I'll have to be adding variations of numerous modules
to get it done so everything links and works correctly when I'd rather just use
what CMake already provides.
$0.02
Ben
On Thursday, May 14, 2015 11:16 AM, Nagy-Egri Máté Ferenc via CMake
cmake@cmake.org wrote:
!--#yiv8924383255 p.yiv8924383255MsoListParagraph, #yiv8924383255
li.yiv8924383255MsoListParagraph, #yiv8924383255
div.yiv8924383255MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;}#yiv8924383255
p.yiv8924383255MsoNormal, #yiv8924383255 li.yiv8924383255MsoNormal,
#yiv8924383255 div.yiv8924383255MsoNormal
{margin:0in;margin-bottom:.0001pt;}#yiv8924383255
p.yiv8924383255MsoListParagraphCxSpFirst, #yiv8924383255
li.yiv8924383255MsoListParagraphCxSpFirst, #yiv8924383255
div.yiv8924383255MsoListParagraphCxSpFirst, #yiv8924383255
p.yiv8924383255MsoListParagraphCxSpMiddle, #yiv8924383255
li.yiv8924383255MsoListParagraphCxSpMiddle, #yiv8924383255
div.yiv8924383255MsoListParagraphCxSpMiddle, #yiv8924383255
p.yiv8924383255MsoListParagraphCxSpLast, #yiv8924383255
li.yiv8924383255MsoListParagraphCxSpLast, #yiv8924383255
div.yiv8924383255MsoListParagraphCxSpLast
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;line-height:115%;}--This
is more of a remark, or something to get the ball rolling, rather than
anything else.
I recently came across various FindModule.cmake files (FindOpenCL, FindOpenGL,
FindGLEW, FindGLM, FindSFML) as a sideeffect of a project I am developing, but
have had my share with quite a few others (FindQt, RustCMake, FindOpenAL,
FindBoost, …). My overall impression is that the quality of these modules is
highly fluctuating to say the least. While generally the FindModules shipping
with CMake as built-in scripts are usable, there is a fair amount of room for
improvement.
FindGLEW.cmake for eg. is terrible. I have never imagined that such a widely
used library has a 7 line FindModule script. On Windows it is practically
useless.
As for nearly all other FindModule scripts, nearly none of them use
target_include_libraries() that would allow for end-users of the scripts to not
have to worry about include directories.
Some projects strive at being cross-platform, but compiling them on Windows
(mostly the GNU projects that aim on being Windows friendly) is massive pain.
libJPEG to name just one provides nmake makefiles that are capable of producing
Visual Studio 2010 project files at best (huuraay), and have undocumented
external dependencies. These projects (and their users) cry out for CMake
support.
Here is a proposition to consider:
Kitware generally has the philosphy with CMake being: do it yourself or hire us
to do it. While on a corporate basis this is a legitimate approach, I as a poor
academic fellow do not have 10.000$ to spare for a feature I so wish, neither
do I have the time to educate myself in the internal ways of CMake to
contribute. So all I do is hack, hack, hack all day.
The Chocolatey project (a package manager for Windows) recently won a massive
Kickstarter campaign that aimed solely increasing the overall quality of the
project. With this campaign they aimed on growing from an ‘interesting idea’ to
begin ‘mainstream’. With the money they won, they hired full time package
moderators, developed automated scripts of facilitating authoring, wrote
tutorials, created templates, and even managed to get the ball rolling with
OneGet (Powershell 5.0 package manager manager) to adopt Chocolatey as the
first supported public repo.
I would suggest Kitware start a similar community funded project to increase
the overall quality of the software. While I do not have 10 grands to buy a
feature, I do have 10 dollars pocket money to contribute (as do MANY others).
As several levels of goals, the stock FindModules scripts could be brought to a
homogenous quality, identical naming conventions (no more MYLIB_INC_DIR,
MYLIB_INCLUDE_DIRS, MyLib_INCLUDE_DIR), high quality templates for new
adopters, make the CMake Guide freely available online (epub, pdf, docx,
whatever), convert 10 GNU projects to CMake, convert 50 GNU projects to CMake,
create Snappy back-end of CPack, or my personal favorite (the feature I do not
have 10.000 dollars for) is NMake batch mode support for multicore build, etc.
There are so many places CMake itself can be improved, and so many users who
really should be adopting, but have not started due to lacking man power.
(These are the projects that would benefit the most from a freely available
tutorial, because truth be told: writing capable, high-quality CMake scripts is
no easy task.)
If I were a
[CMake] CMake finding custom packages...
I'm trying to convert a project over to using CMake. We have a series of
dependency libraries that we custom compile and link against.For a number of
them there is no issue since CMake either has no module for them or there is
nothing to link with.However, I am having trouble with a few of them.
This is all with CMake 2.8.9 as that is what is available under Debian Wheezy
(my build system). I'm not opposed to using a newer version (we already build a
number of things ourselves); but I want to ensure that things would be fixed
before doing so if that was truly the path to resolving the issues.
1. OpenSSL:
SET ( ENV{OPENSSL_ROOT_DIR} /path/to/my/libraries )FIND_PACKAGE(OpenSSL
REQUIRED)
This find OpenSSL, but not the one under /path/to/my/libraries. Are the bug
fixes related to honoring OPENSSL_ROOT_DIR after Cmake 2.8.9?
2. Curl
I've tried a number of methods. Our version of Curl is also built against our
version of OpenSSL; and they are installed under the same path.Further we have
tended to needing to use PkgConfig to get it to work correctly in our previous
build system.
I have tried a number of things, however, I can't seem to get it to reliably
find Curl. (I had it, then I cleaned up the environment and it won't find it
again.)My biggest challenge here is that there is no equivalent of
OPENSSL_ROOT_DIR or any other kinds of hints.I've tried using
FindPackage(CURL...), FindPackage(PkgConfig,...)/PKG_CHECK_MODULES(CURL..).A
co-worker suggested using CMAKE_FIND_ROOT_PATH, but that hasn't helped either.
Any suggestions would be welcome. I'd really like to move us from the old
system to cmake and unify our platforms on a single build system generator so
we don't have to maintain two build environments.
TIA,
Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [Insight-developers] 64 bit build detection
Of course the simpler solution - to include iPhone would be to add ARM detection into that list... Nothing says you couldn't expand the list, my guess is that it was just a first wack at the list... - Original Message From: Michael Wild them...@gmail.com To: Sean McBride s...@rogue-research.com Cc: Michael Jackson mike.jack...@bluequartz.net; cmake Mailing List cmake@cmake.org Sent: Thursday, June 18, 2009 1:44:53 AM Subject: Re: [CMake] [Insight-developers] 64 bit build detection On 18. Jun, 2009, at 0:49, Sean McBride wrote: On 6/14/09 10:05 PM, Michael Wild said: On Mac OS X one shouldn't do this kind of detection during configure step, because as has been mentioned a single file can be compiled multiple times for different architectures during one single compiler invocation. The size of void* and even endianness can change. It is preferable to have a central config.h.in (or similar) containing something like this: #if defined(__APPLE__) # if defined(__i386__) #undef HAVE_64_BIT #undef HAVE_BIG_ENDIAN # elif defined(__ppc__) #undef HAVE_64_BIT #define HAVE_BIG_ENDIAN # elif defined(__x86_64__) #define HAVE_64_BIT #undef HAVE_BIG_ENDIAN # elif defined(__ppc64__) #define HAVE_64_BIT #define HAVE_BIG_ENDIAN # else // oops #error Unknown architecture! # endif #else # cmakedefine HAVE_64_BIT # cmakedefine HAVE_BIG_ENDIAN #endif I agree with Hendrik that such things are better done with types like uin32_t, etc. The quoted stuff above will fail with OS X running on ARM (ie iPhone). Above code for sure is far from ideal or perfect. But sometimes one inherits a code which relies on such details, so here is one relatively simple way to deal with it. And I somehow doubt that there are many codes running both on x86/ppc and iPhone... Besides, uint32_t and related are not present on Windows, so using them is going to break the code there. 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 ___ 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] autoheader
Thanks for the clarifications.
Perhaps my err in this discussion is by referencing the Find functions too
generally, and early on too specifically...
Philip Lowman wrote:
1. Just because you call find_package() on a package doesn't mean that
you need a preprocessor definition in your code in order to use it.
The same is true of checking to see if a function or header file exists
(perhaps just to throw an error if it doesn't).
It is very often these days that one intends merely to build a plugin
by using a 3rd party package in which case adding a global #define via
a config.h file is not wanted at all.
I think that is not really an issue as the modules that do not need to do so
simply would do so. This would, of course, have to be done on a
module-by-module basis, so the module specific find functions would be the only
ones that would be able to make that kind of call. The highly generic functions
would have difficulty there.
Philip Lowman wrote:
There is no guarantee that the find module will pick the proper preprocessor
definitions to define if a package is present. The reason why is that
these vary from project to project.
...
I think that's the strongest argument against it; but then, wouldn't this be
resolved by the package specific find functions (E.g. FindQt4)?
And those functions would just have to worry about changes between versions,
which _should_ be (but won't necessarily be) few and far between, no?
So to be clear - the highly generic functions would not necessarily be of use
to supporting an autoheader style function internally; but the project specific
functions would be able to make good use of it with little to no issue.
Philip Lowman wrote:
It would seem that laying the responsibility of calling
cmake_autoheader() on the find module would limit you to one config.h
header file without really complicating the API.
Again, look at the examples I provided. The user's call to generate the
autoheader could be done multiple times for multiple files while the internals
to add the variables operated more globally so that any single variable was not
added to only one list - but all them. The filtering method (including add and
remove) was provided so a user could limit what they got from the list _if_
they chose to, and per someone's suggestion (see list archives).
So again, I think this is a non-issue.
Philip Lowman wrote:
So basically, it might not always be right and it might not always be
wanted. Not to mention the work involved in retrofitting the find
modules so that they #define the proper stuff.
Isn't it easier to do so once for a single project (e.g. cmake as a whole)
versus every programmer that wants to use the functionality to have to retrofit
their CMakeLists.txt for every little package they want to have autoheader
support for? Someone is going to have to retrofit at some point. So why not do
it in the most reusable way that minimizes cross-project differences and
promotes the most re-use and platform stability?
Philip Lowman wrote:
Perhaps find_package(), check_library_exists(), etc. could be augmented to
optionally support the autoheader api?
I think that makes the good sense.
Philip Lowman wrote:
Regardless of whether or not this happens, as Bill pointed out a user
could always use a wrapper function themselves where it makes sense to.
function(find_package_add_define _pkg)
find_package(${_pkg} ${ARGN})
cmake_autodefine(... HAVE_${_pkg}) # or what-have-you
endfunction()
I think this should be the project designer's _last_ resort for adding a
package; or at the worst a stepping stone while they are waiting on support
from CMake provided functions.
Though where users have to, perhaps we could speed things up by providing an
easy way for them to provide those functions to CMake for others to benefit
from - it'd help generate a series of a project specific functions for it, and
alleviate/speed up the work for CMake devs. I'm sure you already have something
in place this way for the various CMake script functions, and this wouldn't
really be any different - just updating existing ones and adding new ones. The
library would grow.
(Summary) So basically - the autoheader stuff for find functions should more or
less be only supported by module specific functions - not module independent
functions, and we should encourage users (though not require) to send in new
support functions or patches for existing functions that don't support it
already.
Ben___
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] autoheader
On Tue, Mar 31, 2009 at 3:27 PM, BRM bm_witn...@yahoo.com wrote:
Notice my original API suggestion - the project controls its own header - just
not the list of available items.
So essentially:
1) Cmake runs, finds packages, builds list
2) user add extra items to list
3) header generated
Noting from my original API example:
cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package )
cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package )
cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package )
Adding in the filtering as I suggested:
cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package
[filter 1])
cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package
[filter 2])
cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package
[filter 3])
Each project could easily define its own header (or headers) - there would be
no limit. And it should probably generate the header immediately based on when
the cmake_autoheader() is called, based on the state of the list at that point.
(I think it would be too complex to push it until the end of the file; but that
might be possible too.)
As to resolving between sub-projects, it would likely be good to internally
register a scope for the variables - the scope being the path from the root
CMakeLists.txt to the present one. If a parent, sibling, or child node wanted
to access a different node's variables, it would have to do so using the
filters and explicitly name the path. This would be easy to do in the filters
as the project designer would know the paths between the projects. The output
in the header would be no different - just the #define HAS_VARIABLE no matter
what node it was in.
So take the following:
src/CMakeLists.txt
src/subdir1/CMakeLists.txt
src/subdir1/subdir1a/CMakeLists.txt
src/subdir2/CMakeLists.txt
src/subdir1/CMakeLists.txt would be able to access its variables with no
scoping whatsoever. But to access a variable in src/CMakeLists.txt, it would
have to provide explicit scoping to it via a filter when generating the
autoheader via cmake_autoheader(). It would need to do the same to access
variables in either src/subdir1/subdir1a/CMakeLists.txt and
src/subdir2/CMakeLists.txt.
However, I would only guarantee that the cmake_autoheader() would be able to
get what is in the global list at the time it is run. So
src/subdir1/CMakeLists.txt would likely not be able to see
src/subdir2/CMakeLists.txt's variables, or all of the variables in
src/CMakeLists.txt (as some may be defined after src/subdir1/CMakeLists.txt is
run). It could control what it or its child nodes know though - based on when
it makes the call, but that can be left to the project designer.
Quote Philip Lowman phi...@yhbt.com:
===
Why not simply make cmake_autoheader() reentrant (and I assume a command) and
have it process last? This would solve one of your critiques of not having to
pass lists around. You could also eliminate the need to specify the filename
everywhere and a logical name could be used. It would presumably call the
functionality provided by configure_file() internally per logical name.
cmake_autoheader(INIT myconfig ${CMAKE_CURRENT_BINARY_DIR}/config.h)
cmake_autoheader(CONFIG myconfig
... stuff like we already have ...)
add_subdirectory(foo)
foo/ = cmake_autoheader(CONFIG myconfig
... add additional stuff)
Ben's Reply:
=
Only issue I can see with it being re-entrant (good idea overall) is that you
would be limited to having one file. Otherwise love it.
Quote Philip Lowman phi...@yhbt.com:
===
I hear you on trying to automatically add #cmakedefine variables to a list.
Ultimately I think Bill and co. are right that trying to retrofit
find_package() and any other place where you may (or may not) want to add a
#cmakedefine like check_function_exists, etc. is simply going to be too
complex. Also as for find_package() someone out there will certainly want
HAVE_OPENSCENEGRAPH to work instead of HAVE_OSG or HAVE_OSG2 or whatever. You
seem to like HAS_FOO, others probably prefer USE_FOO or HAVE_FOO_H. Clearly
we're never all going to agree.
Even if it was easy to do this there is another risk. Users won't care to
really define which variables they want #cmakedefined or not so they'll simply
define everything. Then you'll end up with what GNU autotools seems to do now
which is to create a ginormous config.h.in file for pretty much anything you
type in configure.ac. Trying to wade through which of these #defines are
actually necessary or not is an annoying exercise in the use of grep. Also
many of these #defines are superfluous on modern compilers/platforms.
Ben's Reply:
=
If you noticed my original API example, I had the Find function use its own
variable for defining the variable. I honestly could care less what
Re: [CMake] autoheader
I think the better solution would be to have the various Find functions (package, library, program) define a variable for that package to an internal list - which is what I think Marcel might have been hinting at. The user could add more variables to the same internal list. So essentially: # package defines its own automatically find_package(some package) if (some_package_found) - cmake_autoheader_add_variable(has_some_package) ... # user can add it too cmake_autoheader_add_variable(has_some_other_package) # user controls what the output file is # User can generate a C #define method (default method if no language is specified) cmake_autoheader(C, path/to/cmake/autoheader_output.h) #User can generate a C++ const methods cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp) ... This would allow CMake to be a true platform for autoheaders as people would not have to think up variables for every project. So FindQt() would add HAS_QT and HAS_QT4 or HAS_QT3 or whatever version it is finding. Perhaps the various variables that the find_package() declares should also be included in the list Just 2 cents. Ben - Original Message From: Bill Hoffman bill.hoff...@kitware.com To: Marcel Loose lo...@astron.nl Cc: cmake@cmake.org Sent: Tuesday, March 31, 2009 7:44:23 AM Subject: Re: [CMake] autoheader Marcel Loose wrote: Hi Bill, Wouldn't it be better if CMake kept track of these variables internally. I mean, usually the HAS_X variables are the result of calls to check_include_file() and check_function_exists(). The Autotools handle this under the hood. CMake might keep a list of these variables, possibly one per check_*() function. Or is there a reason to let the user handle this explicitly by specifying the list of HAS_X variables in the call to cmake_autoheader()? check_include_file does not even have to be used, there are lots of ways to come up with variables that might be useful in a configured header file. I don't really like magic behind the scene lists getting created. Someone could just use a macro for check_include_file that appends to a list if they wanted. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake 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] autoheader
How about: # Each variable can have a registered filter name - packages/programs/libraries would use their name cmake_autoheader_add_variable(has_some_other_package, filter_name) # user controls what the output file is # User can generate a C #define method (default method if no language is specified) cmake_autoheader(C, path/to/cmake/autoheader_output.h [filter_name_list]) #User can generate a C++ const methods cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp [filter_name_list]) - if filter name list is not provided, all entries are entered into the header file - if filter is list is provided: - if name listed and is preceeded by an exclamation (!) then that name is not entered - if name is listed then it is entered - if name is not listed, then it is not entered Likely it would be good to have a parameter that would specify the default behavior of the filter list - enter or not enter - for names not listed. I think a default of 'not enter' would be good if the list is being provided, and this could be overridden and then the list becomes a 'not enter' list. So: # package defines its own automatically find_package(some package) if (some_package_found) - cmake_autoheader_add_variable(has_some_package, some_package) ... # user can add it too cmake_autoheader_add_variable(has_some_other_package, some_other_package) # user controls what the output file is # User can generate a C #define method (default method if no language is specified) cmake_autoheader(C, path/to/cmake/autoheader_output.h some_other_package) #User can generate a C++ const methods cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp some_package) just another 2 cents... Ben - Original Message From: Bill Hoffman bill.hoff...@kitware.com To: James Bigler jamesbig...@gmail.com Cc: CMake cmake@cmake.org Sent: Tuesday, March 31, 2009 11:45:42 AM Subject: Re: [CMake] autoheader James Bigler wrote: If this feature comes to fruition, I would like the ability to specify which flags make it into what header. In one project I worked on all our configuration defines were in a single header. This caused extremely long recompiles if something happened to change the one autoheader. We eventually broke it into multiple files, and got targeted recompiles. I also like the idea of not having to have a configure.h.in http://configure.h.in file like Hendrik Sattler suggested (put these variables in this header here). Do you have an API suggestion? What should this look like? -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake 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] autoheader
Yes, my solution does have a more global variable list. However, I think that in this case it works to your advantage as you only have to build the list once and no one has to explicitly know about each list. This makes using a find function (e.g. FindQt()) easier to write - it just has append to a global list; and its done. Otherwise, you'd have to prove yet-another-parameter to it so it could append to your specific list, but then what if you have more than one list? (e.g. a C header, a CPP header, and a Java header) If you append and pull from a single list, then all three could get all the information from the same run; if otherwise you'd have to provide multiple lists to the various find functions. The disadvantage with the two lines you proposed is that the builder of the list - everyone entering something into the list - would have to know about the file. Where as the method I proposed, everyone would just add on to the list - registering to a master list - and then the project designer could pull out what they want. It has a simplicity to it. Drawing the line on how 'global' the list is is another question - though I would probably make it only as global as the results of any find function would be. (By this, I mean when moving between CMakeLists.txt input files.) Personally, I think that if this is going to be done the API needs to be not just clean, but also elegant. Tacking on another variable to pass in one or more lists to every single find function so you can have the definitions is not clean nor elegant. The alternative to allowing Find functions to do the work for you is to have the user define everything themselves - and that will become very messy, very quickly especially once people start pulling in other CMakified projects from other people. So in this particular case, I think a global list serves the overall need better, and will result a much nicer and easier to use API. Just 2 cents for the pot Ben - Original Message From: Bill Hoffman bill.hoff...@kitware.com To: BRM bm_witn...@yahoo.com Cc: Bill Hoffman bill.hoff...@kitware.com; CMake cmake@cmake.org Sent: Tuesday, March 31, 2009 12:26:04 PM Subject: Re: [CMake] autoheader BRM wrote: How about: # Each variable can have a registered filter name - packages/programs/libraries would use their name cmake_autoheader_add_variable(has_some_other_package, filter_name) # user controls what the output file is # User can generate a C #define method (default method if no language is specified) cmake_autoheader(C, path/to/cmake/autoheader_output.h [filter_name_list]) #User can generate a C++ const methods cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp [filter_name_list]) - if filter name list is not provided, all entries are entered into the header file - if filter is list is provided: - if name listed and is preceeded by an exclamation (!) then that name is not entered - if name is listed then it is entered - if name is not listed, then it is not entered Likely it would be good to have a parameter that would specify the default behavior of the filter list - enter or not enter - for names not listed. I think a default of 'not enter' would be good if the list is being provided, and this could be overridden and then the list becomes a 'not enter' list. So: # package defines its own automatically find_package(some package) if (some_package_found) - cmake_autoheader_add_variable(has_some_package, some_package) ... # user can add it too cmake_autoheader_add_variable(has_some_other_package, some_other_package) # user controls what the output file is # User can generate a C #define method (default method if no language is specified) cmake_autoheader(C, path/to/cmake/autoheader_output.h some_other_package) #User can generate a C++ const methods cmake_autoheader(CXX, path/to/cmake/autoheader_output.hpp some_package) just another 2 cents... I am not sure where things would be stored in this API? Seems to global Maybe the autoheader should be some sort of target... cmake_add_autoheader(C /path/to/cmake/autoheader_output.h) cmake_add_autoheader_variable(/path/to/cmake/autoheader_output.h VAR) -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] autoheader
Notice my original API suggestion - the project controls its own header - just not the list of available items. So essentially: 1) Cmake runs, finds packages, builds list 2) user add extra items to list 3) header generated Noting from my original API example: cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package ) cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package ) cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package ) Adding in the filtering as I suggested: cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package [filter 1]) cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package [filter 2]) cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package [filter 3]) Each project could easily define its own header (or headers) - there would be no limit. And it should probably generate the header immediately based on when the cmake_autoheader() is called, based on the state of the list at that point. (I think it would be too complex to push it until the end of the file; but that might be possible too.) As to resolving between sub-projects, it would likely be good to internally register a scope for the variables - the scope being the path from the root CMakeLists.txt to the present one. If a parent, sibling, or child node wanted to access a different node's variables, it would have to do so using the filters and explicitly name the path. This would be easy to do in the filters as the project designer would know the paths between the projects. The output in the header would be no different - just the #define HAS_VARIABLE no matter what node it was in. So take the following: src/CMakeLists.txt src/subdir1/CMakeLists.txt src/subdir1/subdir1a/CMakeLists.txt src/subdir2/CMakeLists.txt src/subdir1/CMakeLists.txt would be able to access its variables with no scoping whatsoever. But to access a variable in src/CMakeLists.txt, it would have to provide explicit scoping to it via a filter when generating the autoheader via cmake_autoheader(). It would need to do the same to access variables in either src/subdir1/subdir1a/CMakeLists.txt and src/subdir2/CMakeLists.txt. However, I would only guarantee that the cmake_autoheader() would be able to get what is in the global list at the time it is run. So src/subdir1/CMakeLists.txt would likely not be able to see src/subdir2/CMakeLists.txt's variables, or all of the variables in src/CMakeLists.txt (as some may be defined after src/subdir1/CMakeLists.txt is run). It could control what it or its child nodes know though - based on when it makes the call, but that can be left to the project designer. Ben - Original Message From: Clinton Stimpson clin...@elemtech.com To: CMake cmake@cmake.org Sent: Tuesday, March 31, 2009 2:15:25 PM Subject: Re: [CMake] autoheader How would this global auto header stuff work with two sub projects both wanting to do auto headers? Do they share one header, or do they get their own? If they share, what if they both want a different name for the header file? Clint BRM wrote: Yes, my solution does have a more global variable list. However, I think that in this case it works to your advantage as you only have to build the list once and no one has to explicitly know about each list. This makes using a find function (e.g. FindQt()) easier to write - it just has append to a global list; and its done. Otherwise, you'd have to prove yet-another-parameter to it so it could append to your specific list, but then what if you have more than one list? (e.g. a C header, a CPP header, and a Java header) If you append and pull from a single list, then all three could get all the information from the same run; if otherwise you'd have to provide multiple lists to the various find functions. The disadvantage with the two lines you proposed is that the builder of the list - everyone entering something into the list - would have to know about the file. Where as the method I proposed, everyone would just add on to the list - registering to a master list - and then the project designer could pull out what they want. It has a simplicity to it. Drawing the line on how 'global' the list is is another question - though I would probably make it only as global as the results of any find function would be. (By this, I mean when moving between CMakeLists.txt input files.) Personally, I think that if this is going to be done the API needs to be not just clean, but also elegant. Tacking on another variable to pass in one or more lists to every single find function so you can have the definitions is not clean nor elegant. The alternative to allowing Find functions to do the work for you is to have the user define everything themselves - and that will become very messy, very quickly especially once people start pulling in other CMakified projects from other people
Re: [CMake] open source project for CMake ports?
I read through this thread, and I think there may be a better route - Instead of trying to create all kinds of patches, etc; why not make a simple tool to convert an autotool project to CMake and vice-versa? Perhaps call it 'autotool2cmake'? This way, the process becomes simpler: 1) Download source 2) Run tool to convert to CMake (or vice versa) 3) Compile on This would remove the need to keep 'ports' of any project, would not interfere with how the project developers choose to manage their projects, and enable people to get access both ways - without having to worry about insulting one group or the other. Further, the process could be simplified in CMake projects by having a command like: CONVERT_EXTERNAL_SOURCE(project url patch list) CONVERT_EXTERNAL_SOURCE(project url patch dir) Or: # Establish name for the external source, the project, and where to find it CONVERT_EXTERNAL_SOURCE(name project url) # get the version into variable so the project could decide which set of patches to apply EXTERNAL_SOURCE_VERSION(name variable) # apply a set of patches against the named project PATCH_EXTERNAL_SOURCE(name version patch list) PATCH_EXTERNAL_SOURCE(name version patch dir) To (i) implement the process above, and (ii) apply any patches the CMake project maintainer wants to apply against it. And it would give them a stepping stone to such a conversion: a) add support for CMake (or AutoTools) through the utility, release with support for both CMake and AutoTools b) release with support for both but one marked as being deprecated c) drop support for one, continue with using the new, release with just the new Just a thought; it's probably more more useful to all too - especially for projects that decide to move to (or away from) CMake. Ben From: Philip Lowman phi...@yhbt.com To: Luigi Calori l.cal...@cineca.it Cc: CMake Mailing List cmake@cmake.org; a.neundorf-w...@gmx.net Sent: Tuesday, February 17, 2009 8:29:07 AM Subject: Re: [CMake] open source project for CMake ports? On Mon, Feb 16, 2009 at 6:41 PM, Luigi Calori l.cal...@cineca.it wrote: Alexander Neundorf ha scritto: I do not see value in keeping sources (as VTK does) apart from avoid the download-expand step. If the cmake scripts use glob rex expr to get source files, it should be quite resilient to project change and should be easier to mantain. I think that having cmake support for download,unpack and patch would really help. For the first cut I think starting out with keeping the CMakified sources in the project would be fine. Many people are never going to want anything more complicated than this and we know that this will at least work for now. CMake can already untar with -E mode. Adding download support wouldn't be too bad. Not sure how you would handle patching though. A nicer solution than above would be storing the original tarball + patch in the CM of your project and then having CMake untar + apply it at configure time. Then you could optionally add download support on top of that for anyone that wants the ability of their project to properly to build to depend on some server out there in the cloud (not me). -- Philip Lowman ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest question...
It was reporting that it could not find the executable.
However, this was certainly a PEBKAC issue (do'h) - I forgot to have an
ADD_EXECUTABLE() for the test program - or even an
CREATE_TEST_SOURCE_LIST()...though so it shouldn't have been finding it. Though
I am not sure what the best method is...I don't want these executables
installed when I do a 'make install' later...while I am no where near needing
to think about the install process (far too much to go before the project will
be ready for that), it would be good to avoid doing it the
wrong-even-if-it-works way.
Thanks for the tip on the ADD_TEST()...I was simply trying to follow the
referenced WIKI page - it made no mention of needing to define the
EXECUTE_OUTPUT_PATH variable...It probably should be amended to just read as
you mentioned.
I've now got it working. Thanks!
Ben
- Original Message
From: Eric NOULARD [EMAIL PROTECTED]
To: cmake@cmake.org
Sent: Wednesday, November 19, 2008 7:52:49 AM
Subject: Re: [CMake] CTest question...
Le Tue, 18 Nov 2008 15:53:25 -0800 (PST),
BRM [EMAIL PROTECTED] a écrit :
Any info on this? Any better resources?
I think we miss informations about your particular configuration.
I do use ADD_TEST with no trouble.
See more question below:
From: BRM [EMAIL PROTECTED]
To: CMake cmake@cmake.org
Sent: Monday, November 17, 2008 3:14:53 AM
Subject: [CMake] CTest question...
I'd like to build a series of test using the CTest functionality in
CMake. I have added ENABLE_TESTING() to the main CMakeLists, and was
hoping to put the tests in their own sub-directories - as follows:
/
/Tests
/Tests/object
/Tests/object/child-objects
I added the Tests directory in the root's CMakeLists.txt. I've
created my first test (/Tests/object/objectTest) and tried adding it
via ADD_TEST(objectTest ${EXECUTABLE_OUTPUT_PATH}/objectTest})
if objectTest is a target built in /Tests/object/objectTest
then you don't need the extra ${EXECUTABLE_OUTPUT_PATH} just put:
ADD_TEST(objectTest objectTest)
or in order to avoid name clash (I never experienced that but who knows)
ADD_TEST(objectTest_test objectTest)
- no
parameters needed (as described by
http://www.vtk.org/Wiki/CMake_Testing_With_CTest). However, it's
unable to find the test when I run make test.
What is the exact error shown by make test.
Do you get the same error when running
ctest
Note: I tried doing a MESSAGE() to find out the value of
EXECUTABLE_OUTPUT_PATH and it seems to be NULL. Is that reall the
right variable?
I don't think EXECUTABLE_OUTPUT_PATH is set by CMake unless you
decide to set it yourself. The default behavior of cmake is to put
built executable in CMAKE_CURRENT_BINARY_DIR.
Did you set EXECUTABLE_OUTPUT_PATH is your main CMakeLists.txt?
The documentation on ENABLE_TESTING() mentions that CTest expects
files in build's root directory. Does that also apply to ADD_TEST()?
(no mention in ADD_TEST()'s documentation of this).
This is true for me but I do not use absolute file specification with
ADD_TEST, my ADD_TEST use target name previsouly built with
ADD_EXECUTABLE with no problem.
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest question...
Any info on this? Any better resources?
TIA,
Ben
- Original Message
From: BRM [EMAIL PROTECTED]
To: CMake cmake@cmake.org
Sent: Monday, November 17, 2008 3:14:53 AM
Subject: [CMake] CTest question...
I'd like to build a series of test using the CTest functionality in CMake.
I have added ENABLE_TESTING() to the main CMakeLists, and was hoping to put the
tests in their own sub-directories - as follows:
/
/Tests
/Tests/object
/Tests/object/child-objects
I added the Tests directory in the root's CMakeLists.txt. I've created my first
test (/Tests/object/objectTest) and tried adding it via ADD_TEST(objectTest
${EXECUTABLE_OUTPUT_PATH}/objectTest}) - no parameters needed (as described by
http://www.vtk.org/Wiki/CMake_Testing_With_CTest). However, it's unable to find
the test when I run make test.
Note: I tried doing a MESSAGE() to find out the value of EXECUTABLE_OUTPUT_PATH
and it seems to be NULL. Is that reall the right variable?
The documentation on ENABLE_TESTING() mentions that CTest expects files in
build's root directory. Does that also apply to ADD_TEST()? (no mention in
ADD_TEST()'s documentation of this).
Advice appreciated.
TIA,
Ben
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES problem...
Thanks for the tip - it showed that it indeed working; and pointed to a
portability problem in the code -
Using VC++ folder\file is allowed; however, with g++ under Linux it has to be
folder/file.
The g++ notation should work with VC++ too.
Thanks all for the help in finding the issue.
Ben
- Original Message
From: Bill Hoffman [EMAIL PROTECTED]
To: BRM [EMAIL PROTECTED]
Cc: Christopher Harvey [EMAIL PROTECTED]; CMake cmake@cmake.org
Sent: Sunday, November 16, 2008 3:31:38 AM
Subject: Re: [CMake] INCLUDE_DIRECTORIES problem...
BRM wrote:
${project_SOURCE_DIR} is pointing to the root as I thought it would be.
Another suggestion was to use ${PROJECT_SOURCE_DIR} however, that is an empty
string.
I have also tried setting a new variable to ${project_SOURCE_DIR}/include and
using that, however the same result.
I forgot to mention in the earlier e-mail - as I'm running this on Gentoo
(which has used it for several projects), I am using CMake 2.4 - latest from
Portage.
Do a make VERBOSE=1 and check the actual compile line. It maybe a previous -I
that is eating this -I.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] INCLUDE_DIRECTORIES problem...
I have a project with the following layout where '/' is the root of the project
workspace:
/
/project
/project/CMakeLists.txt
/project/source here
/include
/include/project
/include/project/headers here
/CMakeLists.txt
To be clear - I am doing an out-of-source build at /build (again).
This is okay. I finds the source and all, and tries to build; however, it
doesn't find the includes.
I have tried adding the following line to both the /CMakeLists.txt and
/project/CMakeLists.txt:
INCLUDE_DIRECTORIES(${project_SOURCE_DIR}/include)
(assuming 'project' is the name of the project).
However, every time I run 'make' it complains about not being able to find the
include files.
I know I did this a few years back on a project I no longer have access
to. So I know it is doable, but for some reason, I am having problems
with it.
What am I doing wrong?
Ben
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INCLUDE_DIRECTORIES problem...
${project_SOURCE_DIR} is pointing to the root as I thought it would be.
Another suggestion was to use ${PROJECT_SOURCE_DIR} however, that is an empty
string.
I have also tried setting a new variable to ${project_SOURCE_DIR}/include and
using that, however the same result.
I forgot to mention in the earlier e-mail - as I'm running this on Gentoo
(which has used it for several projects), I am using CMake 2.4 - latest from
Portage.
Ben
- Original Message
From: Christopher Harvey [EMAIL PROTECTED]
To: BRM [EMAIL PROTECTED]
Cc: CMake cmake@cmake.org
Sent: Sunday, November 16, 2008 12:45:54 AM
Subject: Re: [CMake] INCLUDE_DIRECTORIES problem...
what is ${project_SOURCE_DIR} ?
try adding MESSAGE(project_SOURCE_DIR is '${project_SOURCE_DIR}')
right before that line in your cmakelists. I have a sneaking suspicion
it's not what you think it is. You have to use something like
${project_SOURCE_DIR}/../include instead.
BRM wrote:
I have a project with the following layout where '/' is the root of the
project workspace:
/
/project
/project/CMakeLists.txt
/project/source here
/include
/include/project
/include/project/headers here
/CMakeLists.txt
To be clear - I am doing an out-of-source build at /build (again).
This is okay. I finds the source and all, and tries to build; however, it
doesn't find the includes.
I have tried adding the following line to both the /CMakeLists.txt and
/project/CMakeLists.txt:
INCLUDE_DIRECTORIES(${project_SOURCE_DIR}/include)
(assuming 'project' is the name of the project).
However, every time I run 'make' it complains about not being able to find
the include files.
I know I did this a few years back on a project I no longer have access
to. So I know it is doable, but for some reason, I am having problems
with it.
What am I doing wrong?
Ben
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
- Original Message From: Andreas Pakulat [EMAIL PROTECTED] To: cmake@cmake.org Sent: Wednesday, September 3, 2008 3:59:08 PM Subject: Re: [CMake] Bug? Broken header files in Visual C++ 2008 project On 03.09.08 17:52:02, Alexander Neundorf wrote: On Thursday 28 August 2008, Andreas Pakulat wrote: On 28.08.08 10:16:48, BRM wrote: ... IMHO the approach to regenerate project description files for an IDE from a buildsystem tool is simply broken. Well, it has to. Otherwise the project file become wrong. That's not a big problem for the makefile-based project generators (KDevelop, Eclipse, CodeBlocks), but a real one for XCode and MSVC. Yeah, I guess I'm really just too used to proper IDE's that don't re-invent the wheel and separate buildsystem from project config properly. Unfortunately as others have already pointed out - proper something that IDE developers have yet to agree on. And unfortunately MSVC and XCode are probably the heavy weights for C/C++ development at this time too. since I can't (by CMake's functionality) add headers to the project. So if you do add_executable(foo foo.c foo.h) foo.h is ignored and doesn't appear in the list of project files ? As far as I understand that does work, but its not what BRM wants, because the header files are not compiled at all. I'm sure it does work as you say, and that is correct - it's not what I want. Consider the following structure: projectdir/ projectdir/include projectdir/source Now, there is a CMakeLists.txt file in projectdir/ and on in projectdir/source (perhaps one in every sub-directory of it too). The header files are all stored in projectdir/include; the source files are all in projectdir/source. In other words, there is a clear delineation of what is compiled and what is not. Now consider that there may be common files used by several projects, and a directory structure similar to the following: dir/include/ dir/project1dir/ dir/project2dir/ ... Now using the same structure in MSVC, I can tell the project itself about its header files - whether they are internal to it (e.g. dir/project1dir/include) or shared (e.g. dir/include); but as CMake presently works (without the ADD_HEADER()) I cannot get CMake to do the same for all IDEs that support such a feature through a simple means. The only choice I am presented with is to make precompiled headers and add them as source, but I am not working with (nor do I desire to work with) precompiled headers or call my headers source - they are explicitly not source, just _definitions_ of functions, structures, types, and objects. Is this not a simple concept? Since I can't do the above, I currently have to search around the source files that are part of the project to find one that includes the header file I want to look at, and then use the IDE's functionality to oen it through the #include statement. Where as before, I could have just opened it from the file list in the IDE. Quite annoying I must say, but the only way to work with projects generated by CMake at the moment. KDevelop3 doesn't need that information at all, or rather it completely ignores the CMake files anyway. Which files do you mean with the CMake files ? Everything related to CMake, i.e. CMakeLists.txt, the stuff in the builddir and so on. Yes, everything in the CMakeLists.txt file - the directories being recursively processed, the source, the headers, the preprocessor defintitions, etc. (Note: I may include one set of headers for one platform and a different set for a different platform. Platform = OS+Processor.) The generator for KDevelop3 projects in CMake is ok if you want to get an initial project status, but after that you shouldn't use it anymore. Why ? Because it overwrites project settings that you have in the .kdevelop file. Thinking about it, the KDevelop3 generator should probably only touch the .filelist and only create the .kdevelop file if its not there yet. Or has that improved since I last tried it out? (which is quite some time ago to be honest). FYI - as stated earlier, I will switch being build types - clear out all the generated project data and switch to a different build system; or re-run CMake to update the build system when a new file(s) has been added to the project. Eventually, I will be even adding dependency information (to perform SVN exports of _released_ modules - not head, but specific releases) to ensure all dependencies that are within my repository are satisfied in a consistent manner and programs don't get borked b/c of a change one module made. Like it or not, CMake does do project management _when_ you define project management as managing the source and dependencies that builds the project. CMake already does a lot of that by auto-detecting dependencies (e.g Qt, KDE, etc.); and adding custom commands to checkout specific releases of internal code is fine - they're custom
Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
Question: What about those of us that do not want the header files compiled (no pre-compiled headers, etc.), but still want the folders to show up in Visual Studio (or any other IDE)? Personally, I think that having to add them as 'source' when they are explicitly _not_ source but definitions is the wrong thing. I love CMake; but not having them listed unless I put them in as source leads to productivity issues too - since I now have to remember which files the headers were included in, find the include line, and open the file from there. Why not having a simple add_headers() function for the project too? That would solve the problem for any IDE, and make things cleaner in the projects too; as well as give the user the option of pre-compiled vs. no pre-compiled headers. (And in case you're wondering, I am not a fan of pre-compiled headers by any measure; I rather try to avoid them.) Ben - Original Message From: Thomas T. [EMAIL PROTECTED] To: CMake Mailinglist cmake@cmake.org Sent: Wednesday, August 27, 2008 7:10:52 PM Subject: [CMake] Bug? Broken header files in Visual C++ 2008 project Hi CMakers! CMake is a great tool for cross-platform development, thanks! There is just one thing that is disturbing my workflow: After searching the forums, and coming up with no working solution, I would like to ask about including headers in a Visual C++ 2008 project with cmake -G Visual Studio 9 2008. Without including them, a lot of IDE features like code completion (IntelliSense), class browser, search and replace, and the file browser are broken for things that are in a library project's headers, so it is not really a cosmetic but a real productivity issue. The problem is, CMake seems not to provide an option to specifically include the .h files explicitly as headers, but only as source files like the .cpp files. It might have worked in previous versions of Visual Studio, I have not tested it, but in 2008, the compiler tries to compile the .h files if they are passed as parameters to add_library or add_executable as the mailinglist archives suggest for previous versions of Visual Studio. When opening the generated Visual C++ 2008 project, the header files are there and even in the right filter folder since I use source_group() and file(GLOB_RECURSE ...). However, when I compile, the compiler tries to compile the header files as if they were .cpp files, which leads to all kinds of strange results - from warnings about no public symbols for object file to linker errors about undefined external symbols for functions that are declared in a .h file, but implemented in a .cpp file. It seems the root of the problem is that CMake adds them as source files, not as headers, but there must be another way to do it - probably we need to file a bug? Cheers, Thomas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
My objection is to do thing following (taken from John's example):
ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_HDRS}
${UPMC_CROP_MOC_HDR} ${UPMC_CROP_RC_SRCS} ${UPMC_CROP_UI_HDRS}
)
I would rather having something like this instead:
ADD_HEADER( CropDICOMImages ${UPMC_CROP_HDRS}
${UPMC_CROP_MOC_HDR} ${UPMC_CROP_UI_HDRS}
)
ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_RC_SRCS}
)
The
first tells me all that stuff goes into compiling the project; but it
ends up making things confusing as it ends up calling the headers
source.
The second tells me that the *_SRCS actually make up
the executable, and the *_HDRS are just headers and NOT part of the
source but something else.
When working with projects I tend to
put headers into different areas based on their use - are they solely
for that project (okay, #include header and its in the same
directory), or are they shared (okay, #include header, and its
in a common include directory). In some respects, it would be nice to
be able to even differentiate them in the IDE - common headers vs.
project headers - but that could probably be done using the filters,
etc. (no biggie); _BUT_ I can't get them to even come up unless I treat
them as SOURCE, which they are not - they're just definitions of what
is in the source for shared usage.
This is probably what has kept me from using KDevelop3 as much too - I tend
towards using CMake to generate Makefiles under Linux b/c it's easier to get to
things than trying to find a source file with
the header in KDevelop3 since I can't (by CMake's functionality) add
headers to the project. It's the same with Visual Studios,
though I have tended to use VS more for other reasons. (I haven't
decided on an IDE under Linux, and have historically just used
Vi+virtual consoles/konsole to do development; where as all my Windows
development has typically been under Visual Studios.)
Any
how...I think the differentiation (clarity) provided by the
ADD_HEADER() proposed above would be good and helpful to a lot of
others than just myself.
Ben
P.S. John - sorry for the double post to you; meant to send it to the list
initially.
- Original Message
From: John Drescher [EMAIL PROTECTED]
To: BRM [EMAIL PROTECTED]; CMake Mailinglist cmake@cmake.org
Sent: Thursday, August 28, 2008 10:16:18 AM
Subject: Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
What about those of us that do not want the header files compiled (no
pre-compiled headers, etc.), but still want the folders to show up in Visual
Studio (or any other IDE)?
That is how it works in my example.
John
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
Sorry for not posting in-line, but the Yahoo! e-mail editor makes it quite
hard...
CMake does a wonderful job at _managing_ build systems and helping with
projects move between environments, and yes even IDEs, etc. It's one of the big
reasons I like it - the fact that I can run CMake and get Makefiles, and run it
again - generate the build system for another tool that works via an IDE. I do
it frequently with the projects I use it for.
Furthermore, the 'build environment' (e.g. KDevelop3, Visual Studios) should
not need to have any concept of what CMake does. It ought to ignore it. CMake,
like GNU Autotools, abstracts the source from the build tools themselves.
_However_, it should generate projects that work consistently with the expected
process flow of the build environments it supports via its generators. And
(IMHO) I would argue that _not_ having functionality such as the proposed
ADD_HEADER() violates that concept.
In essence - yes, CMake is not a project management tool. BUT it is a build
system management tool, and like it or not, that means it is also part of the
build workflow process management chain, which carries with it expectations on
how it interfaces with certain generators such as IDEs, and the generally
accepted (by _its users_) workflow for those IDEs.
BTW, this is not a big thing to be asking for. I wouldn't also define an
ADD_HEADERS() as being project management. We're still talking about build
tools and build systems. Some (e.g. IDEs) carry additional expectations that
others don't. So for those that do have those expections, and ADD_HEADERS()
would be great to have and the generators can make use of; for those that
don't, the generators can simply ignore it.
Ben
- Original Message
From: Andreas Pakulat [EMAIL PROTECTED]
To: cmake@cmake.org
Sent: Thursday, August 28, 2008 3:26:36 PM
Subject: Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
On 28.08.08 10:16:48, BRM wrote:
My objection is to do thing following (taken from John's example):
ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_HDRS}
${UPMC_CROP_MOC_HDR} ${UPMC_CROP_RC_SRCS} ${UPMC_CROP_UI_HDRS}
)
I would rather having something like this instead:
ADD_HEADER( CropDICOMImages ${UPMC_CROP_HDRS}
${UPMC_CROP_MOC_HDR} ${UPMC_CROP_UI_HDRS}
)
ADD_EXECUTABLE( CropDICOMImages ${UPMC_CROP_SRCS}
${UPMC_CROP_MOC_SRCS} ${UPMC_CROP_RC_SRCS}
)
The
first tells me all that stuff goes into compiling the project; but it
ends up making things confusing as it ends up calling the headers
source.
The second tells me that the *_SRCS actually make up
the executable, and the *_HDRS are just headers and NOT part of the
source but something else.
But why should the _buildsystem_ have to declare any of this? There's no
point in doing that, just because some of the generators can't cope with
the header files not being listed somewhere. IMHO the generators should
instead be changed to include those headers into the projects for the
IDE they generate project files for.
When working with projects I tend to
put headers into different areas based on their use - are they solely
for that project (okay, #include header and its in the same
directory), or are they shared (okay, #include header, and its
in a common include directory). In some respects, it would be nice to
be able to even differentiate them in the IDE - common headers vs.
project headers - but that could probably be done using the filters,
etc. (no biggie); _BUT_ I can't get them to even come up unless I treat
them as SOURCE, which they are not - they're just definitions of what
is in the source for shared usage.
IMHO the approach to regenerate project description files for an IDE
from a buildsystem tool is simply broken. A buildsystem will never
support all the things in a more complex IDE, so you either stick to
what it generates and never change the result or you change the settings
here and there but then you can't have CMake re-generate the project
files.
This is probably what has kept me from using KDevelop3 as much too - I tend
towards using CMake to generate Makefiles under Linux b/c it's easier to get
to things than trying to find a source file with
the header in KDevelop3 since I can't (by CMake's functionality) add
headers to the project.
KDevelop3 doesn't need that information at all, or rather it completely
ignores the CMake files anyway. The generator for KDevelop3 projects in
CMake is ok if you want to get an initial project status, but after that
you shouldn't use it anymore. Instead just use the FileTree to update
the list of sourcefiles every once in a while (see the context menu for
Add files to project). If you don't like your .kdevelop file in the
builddir you can just use KDevelop's Import existing project feature
to import any CMake source dir, setup the builddir for it and be done
with it.
It's the same with Visual Studios
Re: [CMake] Add multiple directories
I'm just thinking here, so please tell me if this wouldn't work...but wouldn't
it be easier to have a CMake macro that could (a) find the SVN (or TSVN)
install, (b) checkout/export from a repository provided at minimal the URL and
revision are provided, and optionally prompts for a user/password, to a
separate directory, and (c) adds the directory the code is checked-out/exported
to to the build? (Perhaps the macro could be in a more generic form to work
with multiple RCS's - e.g. CVS, SVN, VSS, ClearQuest, etc.).
A couple examples:
// Put the files in the build directory
SET(CheckoutPath ${projectname_BINARY_DIR}/rcs_deps)
// Generic RCS tool
RCS_CHECKOUT(RCS, /path/to/repository, 1384, ${CheckoutPath})
// SVN minimal
RCS_CHECKOUT(SVN, https://url.to.repository, r1384, ${CheckoutPath})
// CVS minimal
RCS_CHECKOUT(CVS, https://url.to.repository, 1384, ${CheckoutPath})
// SVN with user name and password prompt
RCS_CHECKOUT(SVN, https://url.to.repository, r1384, ${CheckoutPath},
RCS_USERNAME_AND_PASSWORD_PROMPT)
// CVS with user name and password prompt
RCS_CHECKOUT(CVS, https://url.to.repository, 1384, ${CheckoutPath},
RCS_USERNAME_AND_PASSWORD_PROMPT)
// SVN with anonymous user
RCS_CHECKOUT(SVN, https://url.to.repository, r1384, ${CheckoutPath},
RCS_USE_ANONYMOUS_USER)
Perhaps even allow for some macros of the RCS tool:
// Retrieve the revision from the svn:external property list at the given path.
RCS_CHECKOUT(SVN, https://url.to.repository, SVN_EXTERNAL_PROP_GET(PATH,
DEPENDANCY_REVISION), ${CheckoutPath})
Just a thought...would be very useful to help with cross-repository
dependencies.
Ben
- Original Message
From: Alexander Neundorf [EMAIL PROTECTED]
To: cmake@cmake.org
Sent: Monday, February 18, 2008 3:40:18 PM
Subject: Re: [CMake] Add multiple directories
On Monday 18 February 2008, Robert Bielik wrote:
I'm setting up a project repository with subversion where I'll have
external libs linked in via svn:externals svn property. Each external lib
will have a CMakeLists.txt file.
Ideally, I'd like to have the possibility to include N subdirectories
without having to alter the CMakeLists.txt file to do it (by just changing
the svn:externals property).
Like:
ADD_SUBDIRECTORY( * )
Can it be done?
Yes.
You could do file(GLOB */ ) or something like this and then iterate over the
result and add each directory.
Or you could
if(EXISTS some_dir)
add_subdirectory(some_dir)
endif(EXISTS some_dir)
if(EXISTS some_other_dir
add_subdirectory(some_other_dir)
endif(EXISTS some_other_dir)
But actually I wouldn't recommend that.
If you do that, you rely on the dirs at the time cmake runs. There could be
additional directories which you don't want to have included in your build
(e.g. a build dir).
And cmake is not automatically rerun if a directory is created.
If you use plain add_subdirectory(), you know that you have to edit the file
and this will always cause cmake to run again.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Codebase Integration Question...
I'm looking at CMake as a possible tool. I've looked at AutoMake/AutoConf in the past and they can meet my needs, but CMake seems like it may be easier. I have yet to deploy a newer solution. I have a number of projects that rely on each other. For example - one project implements a TCP interface, and another project uses that TCP interface to perform networking (e.g. an echo client/server). The project using the interface has a Makefile structured to automatically export the code from CVS: CVS = cvs TCP_RELEASE = TCP_RELEASE_1_0 TCP:TCP/ $(CVS) export -r $(TCP_RELEASE) TCP I am aware the AutoMake/AutoConf has the ability to handle this in the Makefile.am/Makefile.in/etc files. See the following URL for details - http://www.spinics.net/lists/ac/msg00990.html Is there any functionality in CMake that provides this functionality too? Also, while I don't expect this to really be of any issue, I am in the process of converting my CVS repo to Subversion - in case it matters per the commands. I'll likely deploy whatever is the simplest for what I am trying to do. I am interested in CMake as it seems to be very nice for cross-platform development. This is just one more item that is of interest to me and could make CMake even more attractive, especially if it is easy to do. Thanks, Ben ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
