Re: [CMake] Call for Module maintainer volunteers
On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > On 2007-07-26 18:35-0400 Brandon Van Every wrote: > > > On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > >> On 2007-07-26 13:55-0400 Brandon Van Every wrote: > >> > >> > I think it is very important that any experimental releases have no > >> > effect on official CMake installations at all. > >> > >> That's already been stated. I say again, you will not be affected by this > >> proposal at all. > > > > That's not the point. The point is to define the exact mechanism by > > which this is guaranteed. Just having people download "official" > > CMakes or "experimental" CMakes at their whim won't guarantee it. > > People will get confused about which CMake they're using. If the > > world starts getting populated by CMakes of uncertain composition, I > > am indeed affected. > > Hmm. That (keeping users from being confused about which version they have) > is what release numbers are for. Thus, I am not at all convinced by your > argument. I don't want a non-standard CMake blowing up my build, unless the user is automatically banged over the head with a wooden mallet that they're using a non-standard CMake. People put tools in paths and forget about them. They have no idea what they're using. I don't want to write a bunch of extra query logic to determine what they are using. And I know in the real world, most CMakeLists.txt authors won't write that logic. I've seen the endgames of DirectX capability queries and they ain't pretty. If some builds gotta have experimental module stuff, and other builds gotta *not* have experimental module stuff, the user's got a problem. Is he gonna maintain 2 different CMakes all the time? That's dumb, and he'll screw it up too. I'm a buildmaster, I have 5 different Windows compiler environments hermetically sealed off from each other, which I could permute with CMake stable and CMake CVS if I wanted to. Most people aren't buildmasters, they just want to run CMake and have their software. The disambiguation mechanism needs to function automatically for all versions of CMake produced. An "experimental" version should automatically stick out like a sore thumb. > I think the fundamental reason why you are attempting to be a change blocker > on my suggestion to make module releases is you don't feel comfortable with > the free software culture which encourages releases. Stability is one issue. Lack of faith in volunteers actually doing the work is another. > I do feel extremely > comfortable with that culture (I have been living it for the last decade), > and that is why I am encouraging the CMake developers to start making > module releases. Well then sell Kitware on it. So far it doesn't sound like you take the separation of experimental stuff from official stuff very seriously. I mean geez, entire programming languages like C# have been invented around this kind of "DLL Hell" problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] relinking of exe
On 7/26/07, Jon W <[EMAIL PROTECTED]> wrote: > I have a visual studio project that creates an exe. Even after the > exe is linked and up to date, the next build will relink the exe. > > I'm trying to determine if this is a configuration issue, or a cmake > issue. Has anybody else seen this behavior? You have probably forgotten or mis-stated some weird dependency issue. I had a trouble reminiscent of that when I was doing weird things with static linking. I did things in a more normal manner and the problem went away. Bear in mind the problem of file level dependencies vs. target level dependencies. Too tired to say any more about that, search the mailing list archives. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 2007-07-26 18:35-0400 Brandon Van Every wrote: On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: On 2007-07-26 13:55-0400 Brandon Van Every wrote: > I think it is very important that any experimental releases have no > effect on official CMake installations at all. That's already been stated. I say again, you will not be affected by this proposal at all. That's not the point. The point is to define the exact mechanism by which this is guaranteed. Just having people download "official" CMakes or "experimental" CMakes at their whim won't guarantee it. People will get confused about which CMake they're using. If the world starts getting populated by CMakes of uncertain composition, I am indeed affected. Hmm. That (keeping users from being confused about which version they have) is what release numbers are for. Thus, I am not at all convinced by your argument. I think the fundamental reason why you are attempting to be a change blocker on my suggestion to make module releases is you don't feel comfortable with the free software culture which encourages releases. I do feel extremely comfortable with that culture (I have been living it for the last decade), and that is why I am encouraging the CMake developers to start making module releases. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] relinking of exe
I have a visual studio project that creates an exe. Even after the exe is linked and up to date, the next build will relink the exe. I'm trying to determine if this is a configuration issue, or a cmake issue. Has anybody else seen this behavior? Thanks, Jon ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: On 2007-07-26 13:55-0400 Brandon Van Every wrote: > I think it is very important that any experimental releases have no > effect on official CMake installations at all. That's already been stated. I say again, you will not be affected by this proposal at all. That's not the point. The point is to define the exact mechanism by which this is guaranteed. Just having people download "official" CMakes or "experimental" CMakes at their whim won't guarantee it. People will get confused about which CMake they're using. If the world starts getting populated by CMakes of uncertain composition, I am indeed affected. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 2007-07-26 13:55-0400 Brandon Van Every wrote: I think it is very important that any experimental releases have no effect on official CMake installations at all. That's already been stated. I say again, you will not be affected by this proposal at all. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On Thursday 26 July 2007 12:59, Christian Convey wrote: ... > So Alex provided this command-line: > cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > I've seen "DESTDIR=..." used with "make install". Can I safely use it > (with the expected results) with the cmake command? For example: > > cmake -DDESTDIR=/some/path/ -DCMAKE_INSTALL_COMPONENT=Headers -P > cmake_install.cmake I think the following should work (i.e. keep it an env. variable): DESTDIR=/path cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > And more generally, can I usually assume that any Makefile variable > assignments that work with "make install", such as: >"make install FOO=BAR" > will have the same effect in this command? >"cmake -DFOO=BAR -P cmake_install.cmake" It should have the same effect, but I think it doesn't have a big effect on make install (since this does only cmake -P cmake_install.cmake). Just look at the cmake_install.cmake files, they are not that complicated. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On 7/26/07, Christian Convey <[EMAIL PROTECTED]> wrote:
Thanks, I didn't realize that the cmake program did any of the work
when running 'make'. I thought 'cmake' was executed only when
producing (or rebuilding) the Makefiles, and otherwise was completely
out of the picture when the user invokes 'make'.
Yeah, you get native builds but you're also married to your CMake installation.
In principle there's some kind of "get rid of CMake" mode. In
practice, nobody uses it, so it's not vetted much, and I wouldn't
expect it to work great. Pretty much as you work with CMake builds
over time, you realize you really do want CMake hooking back in to do
stuff for you. So the issue goes away. It's more of a newbie
perception issue ("What?? Why aren't these files standalone??!") or a
corner case for some problem domains ("CMake can't be built on this
device.")
When contracting with a client, I do make it clear that I'm not
providing "standalone" native build system files, so that they know
exactly what the deliverables are and don't think they're supposed to
sue me. 8-) If the client insisted that the native builds had to be
standalone, that having to install CMake is a dealbreaker, then I'd
research the capability more thoroughly. I'd figure out what it would
take to guarantee it in the real world, and pitch / bill accordingly.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: On 2007-07-26 12:32-0400 Brandon Van Every wrote: > > So why will the experimental testing method be widely used? And when > it is used, why will people report their results? This is standard fare in most free software releases these days. To name just a few major projects off the top of my head, the Linux kernel, Debian, KDE, and GNOME projects do this, These have a critical mass of tweakerheads that CMake does not have. People who think it's important to recompile their kernel and their libraries for their specific CPU and so forth. and there are huge numbers of minor projects (such as PLplot) that do this as well. That would be more comparable to CMake's current popularity and scope. The way this works is a given software package puts out a testing release, and the cutting-edge types who are attracted by the new features in the test release, test it, report bugs, etc. Most software users are not cutting-edge types and don't bother with testing releases and apparently you are part of that majority. :-) You can reasonably expect a build system engineer to value stability over the bleeding edge. I wager you'll find that true of people in the CMake community. Nevertheless, the testing release model normally works well because there are a substantial minority that do like to be cutting edge. For example, with PLplot our testing releases have substantial popularity judging by their download rate statistics, and we do get valuable feedback from such early-adopter users. Since we value that feedback we make it extremely easy for users to try testing distributions of PLplot, and I call on KitWare to do the same with the modules. I see a difference: PLplot is an end product, not an underlying configuration tool affecting many applications and libraries. Who tweaks Autoconf? Perhaps a survey of the release methodologies of other major configuration tools is in order, i.e. Ant, SCons. I think it is very important that any experimental releases have no effect on official CMake installations at all. The end user should have to make a conscious choice to allow experimental stuff to operate. Configuration options of the form USE_EXPERIMENTAL_MODULE_MODULENAME might do the trick. They'd be OFF by default. Of course, this is a fairly conservative approach and will keep the testing from being widespread. But I think for a build system, conservative has to be the official default. Otherwise CMake's reputation for building things reliably is jeopardized. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 2007-07-26 12:32-0400 Brandon Van Every wrote: On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: So it really boils down to this. If the developers from KitWare are serious about getting widespread testing of modules before they are made part of an official CMake release, then they will test the modules with separate well-publicized releases. That's not correctly phrased. It should be, "If Kitware is serious about gettting widespread testing of modules before they are made part of an official CMake release, then they will publicize an official experimental means of testing them. Other people will have the burden of actually testing the experimental modules and reporting their results." So why will the experimental testing method be widely used? And when it is used, why will people report their results? This is standard fare in most free software releases these days. To name just a few major projects off the top of my head, the Linux kernel, Debian, KDE, and GNOME projects do this, and there are huge numbers of minor projects (such as PLplot) that do this as well. The way this works is a given software package puts out a testing release, and the cutting-edge types who are attracted by the new features in the test release, test it, report bugs, etc. Most software users are not cutting-edge types and don't bother with testing releases and apparently you are part of that majority. :-) Nevertheless, the testing release model normally works well because there are a substantial minority that do like to be cutting edge. For example, with PLplot our testing releases have substantial popularity judging by their download rate statistics, and we do get valuable feedback from such early-adopter users. Since we value that feedback we make it extremely easy for users to try testing distributions of PLplot, and I call on KitWare to do the same with the modules. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On 7/26/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: On 7/26/07, Christian Convey <[EMAIL PROTECTED]> wrote: > On 7/26/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > > On Thursday 26 July 2007 11:58, Christian Convey wrote: > > > Hi Alex, > > > > > > Wouldn't the command: > > > cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > > > > > overwrite the very makefiles that are executing that command? If so, > > > > No, -P means cmake will just execute the given cmake script, i.e. it will not > > generate makefiles or project files etc. > > OK, so "-P" means that cmake won't produce a new Makefile. > > But don't I *need* to create a new Makefile? I thought the goal was > to produce a new Makefile whose "install" target has been affected by > the "-DCMAKE_INSTALL_COMPONENT=Headers" argument. > > If "-P" prevents the creation of a new Makefile, it sounds like we're > discarding the very Makefile that we're trying to create. > > Would you mind clarifying? The CMake generator creates your Makefile and a bunch of other support files and scripts, including cmake_install.cmake. If you choose to manually execute cmake_install.cmake via a custom command, you're merely using what the generator already created, and invoking it the same way the Makefile does. By default, the script would just install everything. By passing -DCMAKE_INSTALL_COMPONENT=Headers, you're getting a different behavior out of it. Nothing will explode because it's all code the generator produced anyways. Thanks, I didn't realize that the cmake program did any of the work when running 'make'. I thought 'cmake' was executed only when producing (or rebuilding) the Makefiles, and otherwise was completely out of the picture when the user invokes 'make'. So Alex provided this command-line: cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake I've seen "DESTDIR=..." used with "make install". Can I safely use it (with the expected results) with the cmake command? For example: cmake -DDESTDIR=/some/path/ -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake And more generally, can I usually assume that any Makefile variable assignments that work with "make install", such as: "make install FOO=BAR" will have the same effect in this command? "cmake -DFOO=BAR -P cmake_install.cmake" Thanks, Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On 7/26/07, Christian Convey <[EMAIL PROTECTED]> wrote: On 7/26/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Thursday 26 July 2007 11:58, Christian Convey wrote: > > Hi Alex, > > > > Wouldn't the command: > > cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > > > overwrite the very makefiles that are executing that command? If so, > > No, -P means cmake will just execute the given cmake script, i.e. it will not > generate makefiles or project files etc. OK, so "-P" means that cmake won't produce a new Makefile. But don't I *need* to create a new Makefile? I thought the goal was to produce a new Makefile whose "install" target has been affected by the "-DCMAKE_INSTALL_COMPONENT=Headers" argument. If "-P" prevents the creation of a new Makefile, it sounds like we're discarding the very Makefile that we're trying to create. Would you mind clarifying? The CMake generator creates your Makefile and a bunch of other support files and scripts, including cmake_install.cmake. If you choose to manually execute cmake_install.cmake via a custom command, you're merely using what the generator already created, and invoking it the same way the Makefile does. By default, the script would just install everything. By passing -DCMAKE_INSTALL_COMPONENT=Headers, you're getting a different behavior out of it. Nothing will explode because it's all code the generator produced anyways. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On 7/26/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: On Thursday 26 July 2007 11:58, Christian Convey wrote: > Hi Alex, > > Wouldn't the command: > cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > overwrite the very makefiles that are executing that command? If so, No, -P means cmake will just execute the given cmake script, i.e. it will not generate makefiles or project files etc. OK, so "-P" means that cmake won't produce a new Makefile. But don't I *need* to create a new Makefile? I thought the goal was to produce a new Makefile whose "install" target has been affected by the "-DCMAKE_INSTALL_COMPONENT=Headers" argument. If "-P" prevents the creation of a new Makefile, it sounds like we're discarding the very Makefile that we're trying to create. Would you mind clarifying? Thanks, Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 7/26/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: So it really boils down to this. If the developers from KitWare are serious about getting widespread testing of modules before they are made part of an official CMake release, then they will test the modules with separate well-publicized releases. That's not correctly phrased. It should be, "If Kitware is serious about gettting widespread testing of modules before they are made part of an official CMake release, then they will publicize an official experimental means of testing them. Other people will have the burden of actually testing the experimental modules and reporting their results." So why will the experimental testing method be widely used? And when it is used, why will people report their results? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
On Thursday 26 July 2007 11:58, Christian Convey wrote: > Hi Alex, > > Wouldn't the command: > cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake > > overwrite the very makefiles that are executing that command? If so, No, -P means cmake will just execute the given cmake script, i.e. it will not generate makefiles or project files etc. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling what "install" does at make-time ?
Hi Alex, Wouldn't the command: cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake overwrite the very makefiles that are executing that command? If so, does that mess up the state of the Make process that's invoking the cmake command shown above? I'm thinking that in order to safely perform the command like that above, I'd need to somehow do this: 1. create two new empty directories, Foo and Bar. 2. invoke that cmake statement you provided, in a way that will use 'Foo' as its CMAKE_BINARY_DIRECTORY 3. cd to Foo 4. invoke "make install DESTDIR=Bar" And since my overall goal is to produce a different Debian .deb package for each distinct install-component... 5. Do my dpkg-deb actions to package the contents of Bar. Can you think of some reason that these 5 steps aren't necessary? Thanks, Christian On 7/26/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote: On Thursday 26 July 2007 11:25, Christian Convey wrote: > I'd like "make install" to install different (named) subsets of files, > depending on my needs. For example, "make output=header-files > install" or "make output=libraries install". > > Is what I'm trying to accomplish even possible? Yes. You need to use the new INSTALL() commands together with the COMPONENT argument. So e.g. install(FILE foo.h bar.h DESTINATION include COMPONENT Headers) install(TARGETS mylibDESTINATION lib COMPONENT Libraries) etc. The names of the components can be chosen freely (don't use "Default"). You still can do only "make install", but you can execute the install script manually, that's the same as what make install does: $ cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake If it doesn't work, let us know. Bye 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
Re: [CMake] Controlling what "install" does at make-time ?
On Thursday 26 July 2007 11:25, Christian Convey wrote: > I'd like "make install" to install different (named) subsets of files, > depending on my needs. For example, "make output=header-files > install" or "make output=libraries install". > > Is what I'm trying to accomplish even possible? Yes. You need to use the new INSTALL() commands together with the COMPONENT argument. So e.g. install(FILE foo.h bar.h DESTINATION include COMPONENT Headers) install(TARGETS mylibDESTINATION lib COMPONENT Libraries) etc. The names of the components can be chosen freely (don't use "Default"). You still can do only "make install", but you can execute the install script manually, that's the same as what make install does: $ cmake -DCMAKE_INSTALL_COMPONENT=Headers -P cmake_install.cmake If it doesn't work, let us know. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Controlling what "install" does at make-time ?
I'd like "make install" to install different (named) subsets of files,
depending on my needs. For example, "make output=header-files
install" or "make output=libraries install".
Is what I'm trying to accomplish even possible? I can't figure out
how to make this controllable at make-time. I can only seem to make
it controllable at ccmake time.
I was thinking to accomplish this by having, inside my CMakeLists.txt
files, something like this:
IF ("${output}" STREQUALS "header-files")
INSTALL_TARGETS(...)
ELSE (...)
INSTALL_TARGETS(...)
ENDIF (...)
I tried something that looked more flexible: branching based on
environent variables.
IF ("$ENV(output)" STREQUALS "header-files")
INSTALL_TARGETS(...)
ELSE (...)
INSTALL_TARGETS(...)
ENDIF (...)
But this too seems to specify *at ccmake time* which branch will be taken.
Any ideas?
I realize that I could create multiple cmake_binary_dirs, one for each
configuration. But this whole process will ideally be driven by
CMake, and I'm concerned that having CMake invoke CMake will make the
system hard to understand and debug.
Thanks,
Christian
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 2007-07-26 03:20-0400 Brandon Van Every wrote: I'll stick to whatever the official CMake version number guarantees. That's fine since in my scheme the official modules would be released exactly as now and you can go on exactly as before. [out of order] Since I have no faith in the quality and speed of a coordinated volunteer release cycle, I don't see value in a separate CMake Module version number. In my scheme individual volunteer module maintainers have just two release responsibilities. (1) Tell the module release manager when their module is ready for widespread testing in the next separate module release. (2) Tell Bill when their module has been tested sufficiently to get into the release of CMake core + official modules. I don't think either of these responsibilities is an onerous burden for the volunteers. However, in the scheme I proposed the module release manager would have some substantial work to do using official KitWare facilities so I don't think that position should be volunteer. So it really boils down to this. If the developers from KitWare are serious about getting widespread testing of modules before they are made part of an official CMake release, then they will test the modules with separate well-publicized releases. If not, then we will have the present situation where Bill is (rightly) reluctant to accept any change to official modules because of worries about lack of testing of the changes. That (justified) reluctance means that the rate of module fixes actually getting into the official release is way below what it should be, and I believe the solution to this problem is separate module releases for testing purposes. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Configuration
Thanks to all.
> > Yes I had, but when I write in the configure.h.cmake "#cmakedefine
> > ${CMAKE_SYSTEM_NAME}" then the result after the configure_file is
> > this: /* #undef Windows */.
>
> You have to do:
> #cmakedefine CMAKE_SYSTEM_NAME
>
> But I think you want this:
> #define THE_SYSTEM_NAME "${CMAKE_SYSTEM_NAME}"
>
Yes this was the solution for my problem.
Greetings
Alexander
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Configuration
On Thursday 26 July 2007 10:43, you wrote:
> Hi Alex,
>
> > > In my configure.h.cmake: #cmakedefine SYSTEM_NAME In my
> > > CMakeLists.txt: CHECK(system SYSTEM_NAME)
> > > CONFIGURE_FILE(configure.h.cmake
> >
> > configure.h)
> >
> > > Is something like this possible?
> >
> > Did you have a look at ${CMAKE_SYSTEM_NAME} ?
>
> Yes I had, but when I write in the configure.h.cmake "#cmakedefine
> ${CMAKE_SYSTEM_NAME}" then the result after the configure_file is this: /*
> #undef Windows */.
You have to do:
#cmakedefine CMAKE_SYSTEM_NAME
But I think you want this:
#define THE_SYSTEM_NAME "${CMAKE_SYSTEM_NAME}"
Bye
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Configuration
Camek, Alexander a écrit :
> Hi Alex,
>
>
>>> In my configure.h.cmake: #cmakedefine SYSTEM_NAME In my
>>> ...
>> Did you have a look at ${CMAKE_SYSTEM_NAME} ?
>>
>
> Yes I had, but when I write in the configure.h.cmake "#cmakedefine
> ${CMAKE_SYSTEM_NAME}" then the result after the configure_file is this:
> /* #undef Windows */.
> Do I need a specific CHECK command that I get the expected result: #define
> Windows
>
> Thanks for your help
>
> Greetins
>
> Alexander
>
Just put
#define SYSTEM_NAME "${CMAKE_SYSTEM_NAME}"
or
#define ${CMAKE_SYSTEM_NAME}
In your configurable file and, I think it will do the job.
But for the second case, you rely on case sensitivity of the content of
CMAKE_SYSTEM_NAME and whether it has invalid characters for C names
Philippe.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Configuration
Hi Alex,
> > In my configure.h.cmake: #cmakedefine SYSTEM_NAME In my
> > CMakeLists.txt: CHECK(system SYSTEM_NAME)
> > CONFIGURE_FILE(configure.h.cmake
> configure.h)
> >
> > Is something like this possible?
>
> Did you have a look at ${CMAKE_SYSTEM_NAME} ?
Yes I had, but when I write in the configure.h.cmake "#cmakedefine
${CMAKE_SYSTEM_NAME}" then the result after the configure_file is this:
/* #undef Windows */.
Do I need a specific CHECK command that I get the expected result: #define
Windows
Thanks for your help
Greetins
Alexander
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Configuration
Hi Alex,
On Thursday 26 July 2007 10:30, Camek, Alexander wrote:
...
> In my configure.h.cmake: #cmakedefine SYSTEM_NAME
> In my CMakeLists.txt: CHECK(system SYSTEM_NAME)
> CONFIGURE_FILE(configure.h.cmake configure.h)
>
> Is something like this possible?
Did you have a look at ${CMAKE_SYSTEM_NAME} ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Configuration
Hi List, First of all thanks for your help and the good job you do here. I have following problem. I want to create a file which is configured during cmake time. That is no problem up to now I have all what I need execept one thing. I need the name of the plattform. How do I solve that problem? Nothing is written at http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks. What I want to do is something like that: In my configure.h.cmake: #cmakedefine SYSTEM_NAME In my CMakeLists.txt: CHECK(system SYSTEM_NAME) CONFIGURE_FILE(configure.h.cmake configure.h) Is something like this possible? Greetings Alexander Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] gettext example?
At 7/26/2007 09:07 AM, gga wrote: Does anyone have a simple gettext example being used with cmake? I wrote such framework for KWWidgets (http://kwwidgets.org) It is pretty hairy though, but I added a fair amount of comments. Check this directory: http://kwwidgets.org/cgi-bin/viewcvs.cgi/CMake/?root=KWWidgets for FindGettext.cmake KWWidgetsGettextExtract.cmake KWWidgetsGettextInitOrMerge.cmake KWWidgetsInternationalizationMacros.cmake i.e.: http://kwwidgets.org/cgi-bin/viewcvs.cgi/CMake/FindGettext.cmake?root=KWWidgets&view=markup http://kwwidgets.org/cgi-bin/viewcvs.cgi/CMake/KWWidgetsGettextExtract.cmake?root=KWWidgets&view=markup http://kwwidgets.org/cgi-bin/viewcvs.cgi/CMake/KWWidgetsGettextInitOrMerge.cmake?root=KWWidgets&view=markup http://kwwidgets.org/cgi-bin/viewcvs.cgi/CMake/KWWidgetsInternationalizationMacros.cmake?root=KWWidgets&view=markup ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
, So, I have to jump in and say something about pkg-config. It simply can not be relied on to be there by CMake. It is not a default package on any commercial UNIX, and many tools like QT do not require it to be installed. It is just another place to look for things. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
On Jul 26, 2007, at 8:38 AM, Alexander Neundorf wrote: On Thursday 26 July 2007 02:47, Brandon Van Every wrote: On 7/25/07, protein <[EMAIL PROTECTED]> wrote: Hi, Since Dev C++ is a nice free IDE in windows and is developing rapidly. Is it possible that one day cmake will support Dev C++ project file generation? As far as I can tell, interest in Dev C++ has waned because its development has gotten stale. People seem more interested in Code::Blocks. http://www.codeblocks.org/ Yes, I tried and cvs snapshots are working without problems. There is a CodeBlocks generator in cmake cvs (in its beginnings). It needs testers, so I'd suggest try CodeBlocks and the generator in cmake cvs. Bye Alex I will throw my hat in the ring on this one.. Eclipse with CDT: Available on Unix/Linux/OS X/Windows Uses GNU Tool Chain by default OpenSource Updated Regularly Uses Makefiles by default so basically CMake supports it. Never tried Code::Blocks.. but I am really happy with Eclipse CDT. -- Mike Jackson Senior Research Engineer Innovative Management & Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] gettext example?
Does anyone have a simple gettext example being used with cmake? I'm looking for something to automate both the .cpp -> .po conversion and merging as well as the .po -> .mo creation. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
On Thursday 26 July 2007 08:54, Mike Jackson wrote: ... > I will throw my hat in the ring on this one.. Eclipse with CDT: > > Available on Unix/Linux/OS X/Windows > Uses GNU Tool Chain by default > OpenSource > Updated Regularly > Uses Makefiles by default so basically CMake supports it. We would be more than happy about a patch which implements an Eclipse generator :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
On Thursday 26 July 2007 02:47, Brandon Van Every wrote: > On 7/25/07, protein <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Since Dev C++ is a nice free IDE in windows and is developing rapidly. > > Is it possible that one day cmake will support Dev C++ project file > > generation? > > As far as I can tell, interest in Dev C++ has waned because its > development has gotten stale. People seem more interested in > Code::Blocks. http://www.codeblocks.org/ Yes, I tried and cvs snapshots are working without problems. There is a CodeBlocks generator in cmake cvs (in its beginnings). It needs testers, so I'd suggest try CodeBlocks and the generator in cmake cvs. Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
Zitat von Olivier Delannoy <[EMAIL PROTECTED]>: On 7/26/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: Zitat von protein <[EMAIL PROTECTED]>: Since Dev C++ is a nice free IDE in windows and is developing rapidly. Is it possible that one day cmake will support Dev C++ project file generation? Probably not unless you write such a generator. The youngest entry in devcpp CVS is 23 month old and the 4.9.9.2 beta release is probably not getting an update, anymore, but it not very stable. The v4 version as an alternative download is close to unusable, too. Not too many chances, I'd say. Some suggest CodeBlocks instead but what shall be the impression of a software that is _only_ available via CVS because its authors do not dare to make a release :-/ I'd suggest to use VCexpress as editor and compile on command line. I don't think code blocks can be compared to VC Express. Surely not but it also has not generator in cmake and not even a current stable release. The explanation on the codeblocks site is just a lame excuse for a missing release management. But that's not on-topic here. I think VCExpress is not a solution that can be used instead of code blocks. It terms of cmake, it is (on windows). VC is probably never going to be available on UNIX So what? You can use KDevelop, then. code blocks is Where is it available. Some random CVS dump doesn't really count unless there is a statement from the developers that a particular version is known to work in a decent way (usually known as release). plus VCExpress cannot be used with gnu compiler suite or other compiler suites. That is something supported by Code Blocks. Wasn't there something about external Makefile projects? In this case, it would, although cmake doesn't support this (yet?) just like the whole codeblocks thing. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] clear INCLUDE_DIRECTORIES
Hello! I am porting large legacy project to cmake build system. For some reason I need to completely clear INCLUDE_DIRECTORIES and rebuild them from scratch at some stage of CMakeLists.txt. Is it possible now ? Thanks ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
On 7/26/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: Zitat von protein <[EMAIL PROTECTED]>: > Since Dev C++ is a nice free IDE in windows and is developing rapidly. > Is it possible that one day cmake will support Dev C++ project file > generation? Probably not unless you write such a generator. The youngest entry in devcpp CVS is 23 month old and the 4.9.9.2 beta release is probably not getting an update, anymore, but it not very stable. The v4 version as an alternative download is close to unusable, too. Not too many chances, I'd say. Some suggest CodeBlocks instead but what shall be the impression of a software that is _only_ available via CVS because its authors do not dare to make a release :-/ I'd suggest to use VCexpress as editor and compile on command line. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake I don't think code blocks can be compared to VC Express. I think VCExpress is not a solution that can be used instead of code blocks. VC is probably never going to be available on UNIX, code blocks is, plus VCExpress cannot be used with gnu compiler suite or other compiler suites. That is something supported by Code Blocks. I don't think code blocks can be compared to VC Express. -- Olivier Delannoy ATER PRiSM Laboratory Versailles University, FRANCE ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
Zitat von Andreas Schneider <[EMAIL PROTECTED]>: Mathieu Malaterre wrote: On 7/25/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: Am Mittwoch 25 Juli 2007 17:40 schrieb Andreas Schneider: > If someone is using GTK2 I've created a nice Module too. But it isn't > used at WengoPhone at the moment and I'm not a Gnome guy. Maybe someone > else wants to take and maintain it. > > http://cmake-modules.googlecode.com/svn/trunk/Modules/GTK2/FindGTK2.cmake Looks a bit oversized, especially since pkgconfig is not limited to unix platform. On Windows, you just have to setup PKG_CONFIG_PATH environment variable correctly to find the stuff. Thus the modules would be useless and the FindPkgConfig.cmake is sufficient. I have to second that. Those FindPackage module are difficult to maintain because they contain such hard coded path instead of using more elaborate solution. For instance which would use pkg-config to search for gtk2. Same comment for python, one should only need to specify which python executable so that cmake deduce correct path see #2257 sorry, but have you really looked at the code of the Module? I see a pkgconfig line for every GTK Module in the FindPackage Module. Yes I did, that's why I said that pkgconfig is sufficient. pkgconfig(glib-2.0 _GLIB2IncDir _GLIB2LinkDir _GLIB2LinkFlags _GLIB2Cflags) If for whatever reason pkgconfig isn't install you can still find the libraries and the headers. Or simply require pkgconfig. You require cmake for building, too. Another piece isn't that hard, then, especially because the precompiled gtk for win32[1] has a pkgconfig at its side and on the other systems its easy to install (if not already). pkg-config is fine to find the path for the libraries and the headers, but it doesn't check if they really exists. Please do not go the way that the autotools went: make _absolutely_ sure by double-checking. No. If you give the user a gun he has the perfect right to shoot himself in the foot. Only installing the pkgconfig file without the rest or moving things around without knowledge is just that. The following compilation will tell the user as well that he messed up. I wouldn't mind such a module (although I really believe that it's not necessary) but please take a look at FindQt4.cmake about using use flag variables to NOT look for every gtk-related libs by default. If every module would do that, we will soon have the same coffee pause as for autotools configure scripts. I really object to that. HS [1]: http://www.gimp.org/win32/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
Oooops, when I looked at the file all I could see were hardcoded paths. sorry for the noise, -Mathieu On 7/26/07, Andreas Schneider <[EMAIL PROTECTED]> wrote: Mathieu Malaterre wrote: > On 7/25/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: >> Am Mittwoch 25 Juli 2007 17:40 schrieb Andreas Schneider: >> > If someone is using GTK2 I've created a nice Module too. But it isn't >> > used at WengoPhone at the moment and I'm not a Gnome guy. Maybe someone >> > else wants to take and maintain it. >> > >> > >> http://cmake-modules.googlecode.com/svn/trunk/Modules/GTK2/FindGTK2.cmake >> >> Looks a bit oversized, especially since pkgconfig is not limited to unix >> platform. On Windows, you just have to setup PKG_CONFIG_PATH environment >> variable correctly to find the stuff. Thus the modules would be >> useless and >> the FindPkgConfig.cmake is sufficient. > > I have to second that. Those FindPackage module are difficult to > maintain because they contain such hard coded path instead of using > more elaborate solution. For instance which would use pkg-config to > search for gtk2. Same comment for python, one should only need to > specify which python executable so that cmake deduce correct path see > #2257 Hi, sorry, but have you really looked at the code of the Module? I see a pkgconfig line for every GTK Module in the FindPackage Module. pkgconfig(glib-2.0 _GLIB2IncDir _GLIB2LinkDir _GLIB2LinkFlags _GLIB2Cflags) If for whatever reason pkgconfig isn't install you can still find the libraries and the headers. pkg-config is fine to find the path for the libraries and the headers, but it doesn't check if they really exists. -- andreas -- http://www.cynapses.org/ - cybernetic synapses ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
Mathieu Malaterre wrote: > On 7/25/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: >> Am Mittwoch 25 Juli 2007 17:40 schrieb Andreas Schneider: >> > If someone is using GTK2 I've created a nice Module too. But it isn't >> > used at WengoPhone at the moment and I'm not a Gnome guy. Maybe someone >> > else wants to take and maintain it. >> > >> > >> http://cmake-modules.googlecode.com/svn/trunk/Modules/GTK2/FindGTK2.cmake >> >> Looks a bit oversized, especially since pkgconfig is not limited to unix >> platform. On Windows, you just have to setup PKG_CONFIG_PATH environment >> variable correctly to find the stuff. Thus the modules would be >> useless and >> the FindPkgConfig.cmake is sufficient. > > I have to second that. Those FindPackage module are difficult to > maintain because they contain such hard coded path instead of using > more elaborate solution. For instance which would use pkg-config to > search for gtk2. Same comment for python, one should only need to > specify which python executable so that cmake deduce correct path see > #2257 Hi, sorry, but have you really looked at the code of the Module? I see a pkgconfig line for every GTK Module in the FindPackage Module. pkgconfig(glib-2.0 _GLIB2IncDir _GLIB2LinkDir _GLIB2LinkFlags _GLIB2Cflags) If for whatever reason pkgconfig isn't install you can still find the libraries and the headers. pkg-config is fine to find the path for the libraries and the headers, but it doesn't check if they really exists. -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 7/25/07, Hendrik Sattler <[EMAIL PROTECTED]> wrote: Am Mittwoch 25 Juli 2007 17:40 schrieb Andreas Schneider: > If someone is using GTK2 I've created a nice Module too. But it isn't > used at WengoPhone at the moment and I'm not a Gnome guy. Maybe someone > else wants to take and maintain it. > > http://cmake-modules.googlecode.com/svn/trunk/Modules/GTK2/FindGTK2.cmake Looks a bit oversized, especially since pkgconfig is not limited to unix platform. On Windows, you just have to setup PKG_CONFIG_PATH environment variable correctly to find the stuff. Thus the modules would be useless and the FindPkgConfig.cmake is sufficient. I have to second that. Those FindPackage module are difficult to maintain because they contain such hard coded path instead of using more elaborate solution. For instance which would use pkg-config to search for gtk2. Same comment for python, one should only need to specify which python executable so that cmake deduce correct path see #2257 2 cents, -Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Call for Module maintainer volunteers
On 7/25/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: On 2007-07-25 14:46-0400 Brandon Van Every wrote: > It also slaves the release cycles of unrelated modules to each other. > [...] True. That is the whole point. I believe the concerns you have expressed are the standard concerns for the release of any software package made up of different components, and I am not arguing that the module releases will be any different in this regard. However, I do argue it is better for the modules to have an independent release cycle than the cmake core since that allows more coherent testing (e.g., of release 1.1.0) of the latest set of modules whose maintainers feel they are ready for such testing. But at this time, I do not trust that volunteers are going to comprehensively shoulder such coordinated work. Kitware has some revenues associated with CMake and they're not even doing it. It's reasonable for volunteers to tend to the versioning of their own package. It's not reasonable to expect them to function effectively as a QA committee. Since I have no faith in the quality and speed of a coordinated volunteer release cycle, I don't see value in a separate CMake Module version number. I'll stick to whatever the official CMake version number guarantees. Let's make this discussion more concrete by taking a specific example. I have put together Ada language support for CMake. The requisite language support modules now work for three platforms, and it is obviously time for much wider testing. Currently, though, the Ada language modules are hidden away on the PLplot svn server. It will definitely be a step in the right direction to get these modules into CMake cvs since that improves the chances they will receive some additional testing. Yep. That's what soliciting volunteers for module maintenance is all about. If they're not getting into CVS then they're not doing anyone any good. However, as potential maintainer of those modules it would be a big step for me to recommend to Bill the Ada modules go into an integrated release of CMake without substantial widespread testing on a variety of platforms, and the cvs version may never get such testing. (Other potential module maintainers have already expressed this concern today.) Well, so? Call me blase, but it's not like everything in CMake works. If you've done a lot of testing in your group, then there's a higher chance that when they're put out into the wild, they'll work well enough for a lot of people. If they don't, hey it's open source and you can do better next time. Most of us are not getting paid for this. I'm making money on my CMake skills at present, but not for shipping modules. I'd go beef up the regex capabilities or the documentation if I had all the time in the world, but I don't, and it generates no revenue for me. Kitware is under similar constraints of ROI and that's why they ask for volunteers. So in an open source context, let's not overthink the level of service we're going to provide to anybody. So having thought a bit more about this, what I believe we need is well-publicized, easy to use, on-going experimental releases of modules. I don't want to deal with a variation on "DLL Hell" in a user's CMake configuration though. I think the bleeding edge people should build CMake from CVS. Or else projects should deploy their own modules as part of their builds, if they want to use unofficial ones. There's a mechanism for loading a user module, although I haven't used it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake support Dev C++
On 7/25/07, protein <[EMAIL PROTECTED]> wrote: Hi, Since Dev C++ is a nice free IDE in windows and is developing rapidly. Is it possible that one day cmake will support Dev C++ project file generation? As far as I can tell, interest in Dev C++ has waned because its development has gotten stale. People seem more interested in Code::Blocks. http://www.codeblocks.org/ Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
