On 7/29/10 5:40 PM, Michael Jackson wrote:
Well luckily there are a whole slew of projects to take a look at.
HDF5 is one. CMake, VTK, ITK, ParaView are some others. Basically you
have a .cmake file that runs all the tests like looking for headers,
structs, functions and stuff like that. Each
Well luckily there are a whole slew of projects to take a look at.
HDF5 is one. CMake, VTK, ITK, ParaView are some others. Basically you
have a .cmake file that runs all the tests like looking for headers,
structs, functions and stuff like that. Each result is put into a
cmake variable. The
I'm now at the point in writing CMake logic where I need to handle the
config.h.in situation, and either have missed the autoheader
equivalent functionality in CMake or it doesn't exist yet. Can
anybody point me to the "right" approach to this? I have so-far
found:
The #cmakedefine mechanism and
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 ord
On Wed, Apr 1, 2009 at 2:13 PM, BRM wrote:
> Simplicity is best, and I think the simplest solution means not having
> user's bloat their CMakeFiles.txt - it should be part of the system provided
> by CMake.
Let me list the reasons I'm opposed to your proposal of *automatically*
having find modu
On Tue, Mar 31, 2009 at 3:27 PM, BRM 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 A
On Tue, Mar 31, 2009 at 3:27 PM, BRM 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 f
On Tuesday 31 March 2009, James Bigler wrote:
...
> Why not something similar to what you proposed, but without the
> intermediate configure.h.in step and being able to specify comments and
> perhaps custom strings. You could also specify things multiple kinds and
> they all just get inserted one
On Tuesday 31 March 2009, Bill Hoffman wrote:
> 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 ha
On Tuesday 31 March 2009, BRM wrote:
> 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.
Something similar exists for FIND_PACKAGE
an be left to the project designer.
Ben
- Original Message
From: Clinton Stimpson
To: CMake
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
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
To: BRM
Cc: Bill Hoffman ; CMake
Sent: Tuesday, March 31, 2009 12:26:04 PM
Subject: Re
t: 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)
>
On Tue, Mar 31, 2009 at 9:45 AM, Bill Hoffman wrote:
> 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 ex
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
From: Bill Hoffman
To: James Bigler
Cc: CMake
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
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
rsion 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
> To: Marcel Loose
> Cc: cmake@cmake.org
> Se
rom: Bill Hoffman
To: Marcel Loose
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 th
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 variab
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
Same here
.. Original Message ...
On Mon, 30 Mar 2009 17:04:00 +0100 "Mike Arthur"
wrote:
>On Monday 30 March 2009 16:58:47 Bill Hoffman wrote:
>> I think you could do this pretty easily in a function, and a command
>> would not be needed. Anyway, does the API look good?
>Looks good to
Am Montag 30 März 2009 17:58:47 schrieb Bill Hoffman:
> So, what would the API be? I am thinking something that you just give a
> list of variables and a file name.
>
> set(VARS HAS_A HAS_B HAS_C)
> set(STRING_VARS STRING_A STRING_B)
> cmake_autoheader(CMAKEDEFINE_VARS ${VARS}
>
On Monday 30 March 2009 16:58:47 Bill Hoffman wrote:
> I think you could do this pretty easily in a function, and a command
> would not be needed. Anyway, does the API look good?
Looks good to me!
--
Cheers,
Mike Arthur
http://mikearthur.co.uk/
___
Po
Hendrik Sattler wrote:
Zitat von Bill Hoffman :
I have seen several requests for an autoheader type function to be
added to CMake. I have never used autoheader, but I gather it takes a
list of variables and generates a config.h.in file automatically. Does
anyone on the list have experience wi
Zitat von Bill Hoffman :
I have seen several requests for an autoheader type function to be
added to CMake. I have never used autoheader, but I gather it takes a
list of variables and generates a config.h.in file automatically. Does
anyone on the list have experience with autoheader? If so,
I have seen several requests for an autoheader type function to be added
to CMake. I have never used autoheader, but I gather it takes a list of
variables and generates a config.h.in file automatically. Does anyone
on the list have experience with autoheader? If so, what would a nice
CMake
27 matches
Mail list logo
