Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote: > On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: >> As "DSL based on Lua" != Lua, assuming Kitware gets rid of >> documentation and bugs in the language might be too optimistic. Look >> for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based >> DSL for hardware description, like Verilog or VHDL, but it's so >> different from Ruby you need to produce the whole documentation again. > > So? So far I'm the only person who has proposed changing Lua syntax. > I've only listed 2 items: excessive quotes and unpack(table). Nothing > would stop anyone from using quotes all over the place or > unpack(table), i.e. standard Lua would still work. It may even be > possible for these minor tweaks to be transparently corrected as far > as 3rd party Lua libraries are concerned. If it's 95% Lua it's still > Lua. We're talking about a 1 page addendum to the docs, tops. > >> Talking about Ruby, could someone please paste his wishlist about >> variable scoping for CMake? (ie what would you like to add: local >> variables which die when you exit the loop, file-scoped variables, >> directory-scoped variables, project-scoped variables, what?). It's >> quite difficult to fix a problem we have not properly defined (at >> least, I have never seen a proper wishlist about this). > > I just want scope, i.e. I don't want global variable names crapping > all over each other. I don't care about any fancy dancy Computer > Science ways of adding extra programmatic features. Other people may > see heavy duty OO or tweaky FP constructs as beneficial for their > build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. Build systems look very different in different places, and assuming that you know whats best for everybody is a good way to make people want to move away from CMake. Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). > But there's clearly a need for > more structure than CMake script has got. As far as I'm concerned the > fancy dancy stuff is just an artifact of the embedded language that > you get "for free," whether it's Lua, Ruby, or Python. None of that > has been enough to propel SCons into the limelight. No, but having (or being) a real programming language is still one of the main benefits of using SCons (IMO). Still, I went with CMake for our build system, primarily due to the superior support for generating Studio project files, and the fact that SCons has *major* performance issues, especially on Windows. I would like to claim that the input to the build systems (Makefiles, SConsctruct, CMakeLists.txt, etc.) should be considered as source code, with all the implications that has: checked into version control, subject to code quality standards, subject to code review, etc. Given that standpoint, having a real programming language in your build system is very natural. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Documentation (CMake CVS)
2007/11/28, Eric Noulard <[EMAIL PROTECTED]>: > 2007/11/28, Alexander Neundorf <[EMAIL PROTECTED]>: > > On Wednesday 28 November 2007, Mike Jackson wrote: > > > Has anyone started a QtAssistant version of the CMake Docs? I was > > > thinking of spending some time trying a few things but I don't want > > > to start something that is already done, or at least farther along > > > than I am.. > > > > > > I built the cvs cmake this morning and nothing really jumped out at > > > me as having been done. > > > > How about a docbook generator ? > > Docbook can be converted to many formats. > > And why not to use Doxygen? Forget my message I think I misunderstood the fact that you want to generate the doc from CMake itself on-the-fly and not during CMake compilation. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changing directory layout with Cpack ?
2007/11/28, Stephen Collyer <[EMAIL PROTECTED]>: > I have a build tree set up like this: > > src/ > builds/linux > builds/win32 > install/linux/bin > install/linux/lib > install/win32 > > where all the source code lives under src, I do out-of-source > builds under builds, and I install built objects into install/linux > and install/win32. How do you do that? 1) make install in each build tree? or do you use 2) make DESTDIR=/path/to/install install ? 3) or did you SET LIBRARY_OUTPUT_PATH EXECUTABLE_OUTPUT_PATH > Now I want to package this up using Cpack, but I want the linux > package to end up with top level dirs > > /bin/ > /lib/ > > and the win32 builds to end up with > > / > > i.e. I want to remove the install/linux and install/win32 > parts of the tree. Is this possible using some combination > of INSTALL and Cpack ? I can't see how at the moment. CPack package all the thing you install using INSTALL concerning path prefix you may use CMAKE_INSTALL_PREFIX in order to influence INSTALL command using __RELATIVE__ PATH if you use absolute path "CMAKE_INSTALL_PREFIX" will not be used. Could you send us some of your INSTALL command usage for linux and win32 case? -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] statically linked executables
Daniel Rueckert wrote: Alan W. Irwin wrote: On 2007-11-28 21:57- Daniel Rueckert wrote: Bill Hoffman wrote: Daniel Rueckert wrote: Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel Sounds like you might have some explicit shared libraries linked into you project with full paths. -Bill Not explicitly. The shared libraries are -lSM, -lICE (part of X11 I believe) and -lm. I have not found any way how to change them into static libraries in cmake. I have attached the linking command generated by cmake: /usr/bin/c++-fno-const-strings -ffloat-store -Wall -O2 -fPIC -static "CMakeFiles/binarize.dir/binarize.o" -o ../bin/binarize -rdynamic -L/vol/vipdata/project/linux-ubuntu-static/lib -L/vol/vipdata/packages/Mesa-6.5/lib -Wl,-Bstatic -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -lznz -lniftiio -lsegmentation++ -lregistration++ -ltransformation++ -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -ltransformation++ -lregistration++ -lsegmentation++ -lniftiio -lznz -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -Wl,-rpath,/vol/vipdata/project/linux-ubuntu-static/lib:/vol/vipdata/packages/Mesa-6.5/lib I would be grateful for any suggestions. Are you sure you have static versions of all your external libraries (including libSM, libICE and libm) installed? Sometimes, the static versions of libraries come in separate developmental packages than the shared versions for Linux so there may be some additional installation you have to do to get the static versions. 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). Yes, the static libraries are available on the system (in the default dir /usr/lib). Thanks, Daniel If you explicitly link in the static libraries it should work. Give full paths to the /usr/libSM.a. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cross compiling
I am trying to make a platform module to generate symbian build files, so I
was reading the cmake wiki article about cross compiling. It seems to make
pretty good sense, but I have a few questions before I get started.
-After making the toolchain cmake file, is the only way to run cmake with
that toolchain set to run from the command line like this?
~/src/build$ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-eldk-ppc74xx.cmake ..
-where do I write the actual script to generate the build files. On symbian
this is one mmp file and an inf file. Is it in
Platform/${CMAKE_SYSTEM_NAME}.cmake (mandatory)?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] suppressing the compiler chooser dialog
On Nov 28, 2007 6:34 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote: > Well, not exactly, but close. We have a variety of different builds and some > only work on some platforms. For instance on windows desktop we have 2 > different builds which both use msvc. > > The goal would basically be to supply a list of builds that are supported > and pick the compiler based on the build name, since we only support a > limited number of platforms. An example of this build list would be: > > windows desktop A > windows desktop B > windows mobile 5 > windows mobile 6 > symbian > etc. I would just send error messages for what I don't support. I would not try to dumb it down. You could inform the user what you actually support with 1 error dialog box, end of problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] suppressing the compiler chooser dialog
Well, not exactly, but close. We have a variety of different builds and some only work on some platforms. For instance on windows desktop we have 2 different builds which both use msvc. The goal would basically be to supply a list of builds that are supported and pick the compiler based on the build name, since we only support a limited number of platforms. An example of this build list would be: windows desktop A windows desktop B windows mobile 5 windows mobile 6 symbian etc. On Nov 28, 2007 3:28 PM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: > Quoting Brandon Van Every <[EMAIL PROTECTED]>: > > > On Nov 28, 2007 5:01 PM, Jesse Corrington <[EMAIL PROTECTED]> > wrote: > >> I am wondering if there is anyway to suppress the compiler picker > dialog > >> that comes up when you first do configure on a cmakelists. For my > project I > >> want to have an option for what build they want and based on that I > would > >> like to set the compiler through cmake script if possible. Is there > anyway > >> to do this? > > > > I don't get it. If I pick a compiler via CMakeSetup, I'm telling you > > what build I want. What do you mean? > > I think what he wants to do it exactly the opposite we usually do. > > Instead of choosing a compiler (for instance, Visual C++), then choose > a build type (Release, Debug, etc) in the CMakeLists.txt depending on > the command line, he seems to want to ask for the build type, then > choose a compiler depending on that. If I have understood correctly, > he wants to say "if build type is debug, use Visual C++ but if build > type is release, use mingw". > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > > ___ > 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] GUI option with dropdown list
On Wednesday 28 November 2007, KSpam wrote: > On Wednesday 28 November 2007 15:25:33 Jesse Corrington wrote: > > Is it possible to add an option to the GUI that has a drop down list for > > choices. I didn't see anyway to do this with the OPTION command. > > I agree that this would be a very nice feature to have! For instance, it > would be great to have a pulldown for CMAKE_BUILD_TYPE. Yes, currently this is not possible, but there is an entry in the bug tracker for that, I think this is one of the oldest entries there. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] suppressing the compiler chooser dialog
Quoting Brandon Van Every <[EMAIL PROTECTED]>: On Nov 28, 2007 5:01 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote: I am wondering if there is anyway to suppress the compiler picker dialog that comes up when you first do configure on a cmakelists. For my project I want to have an option for what build they want and based on that I would like to set the compiler through cmake script if possible. Is there anyway to do this? I don't get it. If I pick a compiler via CMakeSetup, I'm telling you what build I want. What do you mean? I think what he wants to do it exactly the opposite we usually do. Instead of choosing a compiler (for instance, Visual C++), then choose a build type (Release, Debug, etc) in the CMakeLists.txt depending on the command line, he seems to want to ask for the build type, then choose a compiler depending on that. If I have understood correctly, he wants to say "if build type is debug, use Visual C++ but if build type is release, use mingw". -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a CMAKE_CXX_FLAGS without clearing out all the other flags
Thanks, that works for this specific example. As far as setting other flags, is my best bet just to do what I was thinking of removing the flag and re-adding it? On Nov 28, 2007 2:35 PM, David Cole <[EMAIL PROTECTED]> wrote: > Instead of trying it the hard way (specifically for "/subsystem") why > don't you just add "WIN32" to your ADD_EXECUTABLE call? > > CMake will automatically create a console app for ADD_EXECUTABLE with no > flags, and a windows app for ADD_EXECUTABLE with the WIN32 flag... > > Or were you asking because there is a different use for /subsystem, rather > than simply adding WIN32 to your ADD_EXECUTABLE call...? > > > HTH, > David > > On 11/28/07, Jesse Corrington <[EMAIL PROTECTED]> wrote: > > > I want to set the flag /subsystem to "windows" for a vc 2005 build, but > > I don't want to clear out all the flags and set it. The best way I can think > > of to do this is to iterate over the default flags until I get to /subsystem > > and remove it and its value, and then add the flag with the value I want. I > > just want to make sure this is the best way to handle this. Any thoughts? > > > > Thanks > > > > Jesse > > > > ___ > > 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] statically linked executables
Alan W. Irwin wrote: On 2007-11-28 21:57- Daniel Rueckert wrote: Bill Hoffman wrote: Daniel Rueckert wrote: Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel Sounds like you might have some explicit shared libraries linked into you project with full paths. -Bill Not explicitly. The shared libraries are -lSM, -lICE (part of X11 I believe) and -lm. I have not found any way how to change them into static libraries in cmake. I have attached the linking command generated by cmake: /usr/bin/c++-fno-const-strings -ffloat-store -Wall -O2 -fPIC -static "CMakeFiles/binarize.dir/binarize.o" -o ../bin/binarize -rdynamic -L/vol/vipdata/project/linux-ubuntu-static/lib -L/vol/vipdata/packages/Mesa-6.5/lib -Wl,-Bstatic -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -lznz -lniftiio -lsegmentation++ -lregistration++ -ltransformation++ -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -ltransformation++ -lregistration++ -lsegmentation++ -lniftiio -lznz -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -Wl,-rpath,/vol/vipdata/project/linux-ubuntu-static/lib:/vol/vipdata/packages/Mesa-6.5/lib I would be grateful for any suggestions. Are you sure you have static versions of all your external libraries (including libSM, libICE and libm) installed? Sometimes, the static versions of libraries come in separate developmental packages than the shared versions for Linux so there may be some additional installation you have to do to get the static versions. 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). Yes, the static libraries are available on the system (in the default dir /usr/lib). Thanks, Daniel -- Daniel Rueckert, Ph.D. Department of Computing Imperial College London 180 Queens' Gate Tel: +44 20 7594 8333 London SW7 2AZ Fax: +44 20 7581 8024 mailto:[EMAIL PROTECTED] http://www.doc.ic.ac.uk/~dr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] statically linked executables
On 2007-11-28 21:57- Daniel Rueckert wrote: Bill Hoffman wrote: Daniel Rueckert wrote: Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel Sounds like you might have some explicit shared libraries linked into you project with full paths. -Bill Not explicitly. The shared libraries are -lSM, -lICE (part of X11 I believe) and -lm. I have not found any way how to change them into static libraries in cmake. I have attached the linking command generated by cmake: /usr/bin/c++-fno-const-strings -ffloat-store -Wall -O2 -fPIC -static "CMakeFiles/binarize.dir/binarize.o" -o ../bin/binarize -rdynamic -L/vol/vipdata/project/linux-ubuntu-static/lib -L/vol/vipdata/packages/Mesa-6.5/lib -Wl,-Bstatic -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -lznz -lniftiio -lsegmentation++ -lregistration++ -ltransformation++ -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -ltransformation++ -lregistration++ -lsegmentation++ -lniftiio -lznz -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -Wl,-rpath,/vol/vipdata/project/linux-ubuntu-static/lib:/vol/vipdata/packages/Mesa-6.5/lib I would be grateful for any suggestions. Are you sure you have static versions of all your external libraries (including libSM, libICE and libm) installed? Sometimes, the static versions of libraries come in separate developmental packages than the shared versions for Linux so there may be some additional installation you have to do to get the static versions. 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] suppressing the compiler chooser dialog
On Nov 28, 2007 5:01 PM, Jesse Corrington <[EMAIL PROTECTED]> wrote: > I am wondering if there is anyway to suppress the compiler picker dialog > that comes up when you first do configure on a cmakelists. For my project I > want to have an option for what build they want and based on that I would > like to set the compiler through cmake script if possible. Is there anyway > to do this? I don't get it. If I pick a compiler via CMakeSetup, I'm telling you what build I want. What do you mean? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GUI option with dropdown list
On Wednesday 28 November 2007 15:25:33 Jesse Corrington wrote: > Is it possible to add an option to the GUI that has a drop down list for > choices. I didn't see anyway to do this with the OPTION command. I agree that this would be a very nice feature to have! For instance, it would be great to have a pulldown for CMAKE_BUILD_TYPE. Justin ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] setting a CMAKE_CXX_FLAGS without clearing out all the other flags
Instead of trying it the hard way (specifically for "/subsystem") why don't you just add "WIN32" to your ADD_EXECUTABLE call? CMake will automatically create a console app for ADD_EXECUTABLE with no flags, and a windows app for ADD_EXECUTABLE with the WIN32 flag... Or were you asking because there is a different use for /subsystem, rather than simply adding WIN32 to your ADD_EXECUTABLE call...? HTH, David On 11/28/07, Jesse Corrington <[EMAIL PROTECTED]> wrote: > > I want to set the flag /subsystem to "windows" for a vc 2005 build, but I > don't want to clear out all the flags and set it. The best way I can think > of to do this is to iterate over the default flags until I get to /subsystem > and remove it and its value, and then add the flag with the value I want. I > just want to make sure this is the best way to handle this. Any thoughts? > > Thanks > > Jesse > > ___ > 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] GUI option with dropdown list
Is it possible to add an option to the GUI that has a drop down list for choices. I didn't see anyway to do this with the OPTION command. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] suppressing the compiler chooser dialog
I am wondering if there is anyway to suppress the compiler picker dialog that comes up when you first do configure on a cmakelists. For my project I want to have an option for what build they want and based on that I would like to set the compiler through cmake script if possible. Is there anyway to do this? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] statically linked executables
Bill Hoffman wrote: Daniel Rueckert wrote: Hi, I am trying to build some statically linked executables on a linux box. I have added the "-static" option to the linker flags and specified static link libraries but for some reason cmake still adds the option "-Wl,-Bdynamic" flag to the linker options. Is there any way around this? Thanks, Daniel Sounds like you might have some explicit shared libraries linked into you project with full paths. -Bill Not explicitly. The shared libraries are -lSM, -lICE (part of X11 I believe) and -lm. I have not found any way how to change them into static libraries in cmake. I have attached the linking command generated by cmake: /usr/bin/c++-fno-const-strings -ffloat-store -Wall -O2 -fPIC -static "CMakeFiles/binarize.dir/binarize.o" -o ../bin/binarize -rdynamic -L/vol/vipdata/project/linux-ubuntu-static/lib -L/vol/vipdata/packages/Mesa-6.5/lib -Wl,-Bstatic -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -lznz -lniftiio -lsegmentation++ -lregistration++ -ltransformation++ -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -lcontrib++ -limage++ -lgeometry++ -lcommon++ -lrecipes -ltransformation++ -lregistration++ -lsegmentation++ -lniftiio -lznz -lz -lfltk_images -lfltk -lfltk_gl -lfltk_forms -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -lm -Wl,-Bstatic -lglut -lXmu -lXi -lGLU -lGL -Wl,-Bdynamic -lSM -lICE -Wl,-Bstatic -lX11 -lXext -Wl,-Bdynamic -Wl,-rpath,/vol/vipdata/project/linux-ubuntu-static/lib:/vol/vipdata/packages/Mesa-6.5/lib I would be grateful for any suggestions. Daniel -- Daniel Rueckert, Ph.D. Department of Computing Imperial College London 180 Queens' Gate Tel: +44 20 7594 8333 London SW7 2AZ Fax: +44 20 7581 8024 mailto:[EMAIL PROTECTED] http://www.doc.ic.ac.uk/~dr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] GNU Make warnings
Hi, I don't know if its the right place to post this question but I wondered it there is any way to silently suppress makefile warnings ? E.g.: CMakeFiles/Makefile2:1999: warning: ignoring old commands for target CMakeFiles/Makefile2:1601: warning: overriding commands for target ... It is very annoying since it is detected as a compilation warning by Dart2 and it pollute my logs. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Changing directory layout with Cpack ?
I have a build tree set up like this: src/ builds/linux builds/win32 install/linux/bin install/linux/lib install/win32 where all the source code lives under src, I do out-of-source builds under builds, and I install built objects into install/linux and install/win32. Now I want to package this up using Cpack, but I want the linux package to end up with top level dirs /bin/ /lib/ and the win32 builds to end up with / i.e. I want to remove the install/linux and install/win32 parts of the tree. Is this possible using some combination of INSTALL and Cpack ? I can't see how at the moment. -- Regards Steve Collyer Netspinner Ltd ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] setting a CMAKE_CXX_FLAGS without clearing out all the other flags
I want to set the flag /subsystem to "windows" for a vc 2005 build, but I don't want to clear out all the flags and set it. The best way I can think of to do this is to iterate over the default flags until I get to /subsystem and remove it and its value, and then add the flag with the value I want. I just want to make sure this is the best way to handle this. Any thoughts? Thanks Jesse ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 1:28 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote: > On Wednesday 28 November 2007, Brandon Van Every wrote: > > On Nov 28, 2007 3:17 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > > Right now I think it's just an experiment to see how things might > > > work, how much effort would be involved, and how much of an impedance > > > mismatch there will be with how things are currently done. It sounds > > > like things may not progress any further unless a real long term > > > vision for CMake is developed and embraced. > > > > Gee you want one of those? :-) Here's one: happy, shiny programmers > > using a happy, shiny, fullblown programming language to implement > > entire build systems > > I for one really don't want that. > I don't want a full blown programming language in my build scripts. I don't > want to understand actual programs when looking at build files. IMO it is ok > that the cmake language is limited, this way you don't end up with programs > as build files. > This is what can happen if you use scons, then you have programs as build > scripts. And everybody can program something more fancy. IMO this is wrong > for a build system. > > Still having some type of variable scoping would be nice to have :-) I somewhat agree with you. I'm not a fan of "here's this tweaky thing you can do in Lua or Ruby." The few times I've tried to be "helpful" when a group was trying to get their build system off the ground (was it OpenSceneGraph or G3D, I forget?) I railed against programmatic approaches. It's way easier for me to understand straight CMake script than a pile of gratuitous abstractions that some programmer thought would be kewl. *However*, the need for robust scoping has been proven in my own and other people's work. As far as I'm concerned it's not just a "nice to have" item. Strategically, over the next 10 years, it is an essential item to have. Or CMake will someday be regarded as an unacceptable toy, incapable of meeting the complexity requirements of the software of the day. CMake is currently ahead of the competition in terms of capabilities; over the long haul, that happy fact is not guaranteed. Just as we all hate Autoconf now, if CMake is not forwards-looking as far as capabilities, someday we will all hate CMake. [*] Because I see the need for scoping at present, I'm willing to concede the possibility that Object Orientation, or some other higher level organizational paradigm, may be needed in the future. I don't know at what point in the future, and I expect later rather than sooner, but nevertheless technology marches on. ASM code gave way to C code, C code gave way to C++ code, C++ code gave way to Java code. Each generation of programmers claimed a lack of need, and each generation is consistently proven to be partly wrong. The old technologies and paradigms persist, but new technologies and paradigms emerge and capture large chunks of programmer marketshare. I'm sensitive to the imperatives of marketshare. I want more money in CMake consulting. I want more money in Open Source cross-pollenation between Unix and Windows. So, if "fancier programming constructs" make a tool vastly more popular, I take that into consideration. [*] Frankly some people hate CMake now, and they don't make it a secret. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: Trouble with interdependent libraries
This might be circular dependencies between your LibC and LibB libraries. I
had such problem where it worked on Windows but not on Linux. If this is the
case you can solve it by:
TARGET_LINK_LIBRARIES (A B C B)
Or
TARGET_LINK_LIBRARIES (A B C B C.)
I solved it by defining a library that combines both libraries to one
library and add the library file to the source files of every executable
that links against them.
IF(UNIX)
# This is to overcome circular dependencies between ${BUILD_LANGUAGE} and
Generic libs.
# the benefit of doing it this way is that the combined library is only
created once.
SET (COMBINED_LIB ${CMAKE_BINARY_DIR}/lib${BUILD_LANGUAGE}Generic.a)
ADD_CUSTOM_COMMAND(OUTPUT ${COMBINED_LIB}
COMMAND ar ARGS crsv ${COMBINED_LIB} `find ./${BUILD_LANGUAGE} -name
'*.o'` `find ./Generic -name '*.o'`
DEPENDS ${BUILD_LANGUAGE} ${GENERIC_LIBRARIES}
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMENT "Creating a single library from ${BUILD_LANGUAGE} & Generic"
)
# adding the library to SOURCE_FILES creates a dependency of the project
on the library.
SET (SOURCE_FILES ${SOURCE_FILES} ${COMBINED_LIB})
ENDIF(UNIX)
It is not so elegant, but it works.
>I'm working with 3 CMakeLists.txt files I didn't write, so I'm trying to
figure out the reasoning behind them.
>
>-Application A has a CMakeLists.txt file with TARGET_LINK_LIBARIES(LibB,
LibC). -LibB and LibC each have their own subfolders and CMakeLists.txt
>file, and use ADD_LIBRARY to declare their sources to be a library. -LibB
uses some classes defined in LibC.
>
>Under windows, I can run cmake, compile and link without errors. On Linux,
I get linker errors that LibB's uses of LibC are undefined >references. I
tried adding TARGET_LINK_LIBRARY(LibC) to LibB's CMakeLists.txt file, but
that didn't fix the error. Any ideas?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtAssistant Docs (Experimental)
Mike Jackson wrote: The current (as of 11/28/2007 CMake cvs will NOT generate the module html files. I get a seg fault) so I switch to the cmake 2.4.7 part way through to at least What command line did you use to get the seg fault, I can not reproduce the problem. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] QtAssistant Docs (Experimental)
The following shell script is a hack that I created to generate a
rough set of Docs that can be viewed/searched using QtAssistant from
Qt4. There are probably some bugs in the script but it seems to
generate ok on my system. Also, checking the HTML against BBEdit's
HTML validator, there seem to be some HTML generation issues from
cmake itself ( is never closed, seems to be
bad). The current (as of 11/28/2007 CMake cvs will NOT generate the
module html files. I get a seg fault) so I switch to the cmake 2.4.7
part way through to at least get the text versions of those help files.
Comments are welcome. I would like to see this wrapped up as its own
CMake Docs Application or as a "Help.." menu in the QtCmakeSetup app
that is in CVS.
Comments are welcome...
Begin Shell Script
#!/bin/bash
# This is a shell script to generate a QtAssistant set of docs from
the CMake distribution.
#
# Couple of things to get you started with this file:function file
# 1. Set the CMAKE variable to the cmake executable for the CMAKE cvs
if it is not
# the default on your system
# 2. I change the definition of CMAKE to 'cmake' when I generate the
"module" list because
# the current CMake cvs seg faults when I use the cmake --help-module-
list command
# 3. All the files are generated in the /tmp directory. If you want
them somewhere else
# set the 'generationDir' variable
# 4. Launch QtAssistant with the -profile argument, for example on OS
X I use
# ./assistant.app/Contents/MacOS/assistant -profile /private/tmp/
cmake_assistant_docs/CMakeDocs.adp
# where my pwd is: ${QTDIR}/bin or
# /Users/Shared/Toolkits/Qt-4.3.2-UBLib/bin
# Change the 'qtassistant' variable to point to your QtAssistant
executable
qtassistant="${QTDIR}/bin/assistant.app/Contents/MacOS/assistant"
CMAKE="/Users/Shared/OpenSource/CMake/build/bin/cmake"
generationDir="/tmp"
assistantDir="${generationDir}/cmake_assistant_docs"
commandDocDirName="cmake_command_docs"
moduleDocDirName="cmake_module_docs"
commandDocDir="${assistantDir}/${commandDocDirName}"
moduleDocDir="${assistantDir}/${moduleDocDirName}"
tmpHTMLFile="${commandDocDir}${generationDir}.html"
mkdir ${assistantDir}
mkdir ${commandDocDir}
mkdir ${moduleDocDir}
commandListFile="${generationDir}/cmake_command_list.txt"
${CMAKE} --help-command-list ${commandListFile}
#
# Generate all the individual cmake command html files
#
i=0
exec 9<${commandListFile}
while read -u 9 line
do
if [[ ${i} -gt 0 ]]; then
echo ${i}": ${line}"
# Seems that CMake only puts out the body portion of the html
${CMAKE} --help-command ${line} ${tmpHTMLFile}
commandFile=${commandDocDir}/${line}.html
# Clear the file in case it is left over from previous run
echo "" > ${commandFile}
echo "Transitional//EN\"" >> ${commandFile}
echo "\"http://www.w3.org/TR/html4/loose.dtd\";>" >> ${commandFile}
echo "" >> ${commandFile}
echo "charset=UTF-8\"> " >> ${commandFile}
echo "CMake Command ${line}" >> ${commandFile}
echo "" >> ${commandFile}
echo "" >> ${commandFile}
cat ${tmpHTMLFile} >> ${commandFile}
echo "" >> ${commandFile}
fi
let i=i+1
done
exec 9<&-
#
# Generate the CMake command Index File
#
commandIndexFile="command_index.html"
indexFile=${commandDocDir}/${commandIndexFile}
echo "" > ${indexFile}
echo "\"" >> ${indexFile}
echo "\"http://www.w3.org/TR/html4/loose.dtd\";>" >> ${indexFile}
echo "" >> ${indexFile}
echo "charset=UTF-8\"> " >> ${indexFile}
echo "CMake Command Index" >> ${indexFile}
echo "" >> ${indexFile}
echo "" >> ${indexFile}
i=0
exec 9<${commandListFile}
while read -u 9 line
do
if [[ ${i} -gt 0 ]]; then
echo "${line}" >> ${indexFile}
fi
let i=i+1
done
exec 9<&-
echo "" >> ${indexFile}
# Create the Module list file
# Change to current CMake as there is a bug in the cvs cmake
CMAKE=cmake
moduleListFile="${generationDir}/cmake_module_list.txt"
cmake --help-module-list ${moduleListFile}
#
# Generate all the individual cmake module html files
#
i=0
exec 9<${moduleListFile}
while read -u 9 line
do
if [[ ${i} -gt 0 ]]; then
echo ${i}": ${line}"
# Seems that CMake only puts out the body portion of the html
${CMAKE} --help-module ${line} ${tmpHTMLFile}
commandFile=${moduleDocDir}/${line}.html
# Clear the file in case it is left over from previous run
echo "" > ${commandFile}
echo "Transitional//EN\"" >> ${commandFile}
echo "\"http://www.w3.org/TR/html4/loose.dtd\";>" >> ${commandFile}
echo "" >> ${commandFile}
echo "charset=U
Re: [CMake] global variable passing up via INTERNAL cache variable
Erik Johansson wrote: 2007/11/27, James Bigler <[EMAIL PROTECTED]>: I got a hint that I could do this to set values that could be read by the CMakeLists.txt file above: You can also use get_directory_property. See for example how we use it in Licq [1] to get a the list of files from a subdirectory (to implement convenience libs). // Erik [1] - http://trac.licq.org/browser/branches/newapi/licq/src/CMakeLists.txt Thanks. I did know about this, but it didn't fit the requirements I needed. This only helps if you have knowledge of all the directories where you happen to change the global variable. I wanted something that would work without knowing this bit of information. I'm dealing with dozens of directories, and I wanted this to be more automatic. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] global variable passing up via INTERNAL cache variable
2007/11/27, James Bigler <[EMAIL PROTECTED]>: > I got a hint that I could do this to set values that could be read by > the CMakeLists.txt file above: You can also use get_directory_property. See for example how we use it in Licq [1] to get a the list of files from a subdirectory (to implement convenience libs). // Erik [1] - http://trac.licq.org/browser/branches/newapi/licq/src/CMakeLists.txt -- Erik Johansson Home Page: http://ejohansson.se/ PGP Key: http://ejohansson.se/erik.asc ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Documentation (CMake CVS)
2007/11/28, Alexander Neundorf <[EMAIL PROTECTED]>: > On Wednesday 28 November 2007, Mike Jackson wrote: > > Has anyone started a QtAssistant version of the CMake Docs? I was > > thinking of spending some time trying a few things but I don't want > > to start something that is already done, or at least farther along > > than I am.. > > > > I built the cvs cmake this morning and nothing really jumped out at > > me as having been done. > > How about a docbook generator ? > Docbook can be converted to many formats. And why not to use Doxygen? Doxygen supports a pretty good set of output format: http://www.stack.nl/~dimitri/doxygen/output.html Since we talk about documentation which is currently embedded in the source code doxygen is good at extracting doc from code. Using it's lazy grouping features: http://www.stack.nl/~dimitri/doxygen/commands.html#cmdaddtogroup I did not have a look at how CMake doc is currently generated and you speak a "Docbook Generator" meaning that you want to _generate_ docbook doc from currently embedded doc? -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Documentation (CMake CVS)
On Wednesday 28 November 2007, Mike Jackson wrote: > Has anyone started a QtAssistant version of the CMake Docs? I was > thinking of spending some time trying a few things but I don't want > to start something that is already done, or at least farther along > than I am.. > > I built the cvs cmake this morning and nothing really jumped out at > me as having been done. How about a docbook generator ? Docbook can be converted to many formats. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Wednesday 28 November 2007, Brandon Van Every wrote: > On Nov 28, 2007 3:17 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > Right now I think it's just an experiment to see how things might > > work, how much effort would be involved, and how much of an impedance > > mismatch there will be with how things are currently done. It sounds > > like things may not progress any further unless a real long term > > vision for CMake is developed and embraced. > > Gee you want one of those? :-) Here's one: happy, shiny programmers > using a happy, shiny, fullblown programming language to implement > entire build systems I for one really don't want that. I don't want a full blown programming language in my build scripts. I don't want to understand actual programs when looking at build files. IMO it is ok that the cmake language is limited, this way you don't end up with programs as build files. This is what can happen if you use scons, then you have programs as build scripts. And everybody can program something more fancy. IMO this is wrong for a build system. Still having some type of variable scoping would be nice to have :-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to FindQt4.cmake for supporting moc compiler options
Hello,
I just saw the CMake native command qt_wrap_cpp in cmQTWrapCPPCommand.h.
Why would there be a command like this and a macro in FindQt4
(QT4_WRAP_CPP)? Which is the correct one to use?
I think that these commands might obsolete the patch in this thread
and it should rather be supported in the cmake command.
Alex, have you thought of supporting options in the qt_wrap_cpp
commands? What interface would you expect? As indicated below I
encountered the need to pass definitions to the moc compiler and
thought that the following interface would be useful:
QT4_WRAP_CPP( [OPTIONS opt1 opt2 ...])
so that I could do:
QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
I guess this could be applied to the qt_wrap_cpp command...
Comments?
--Miguel
On 11/27/07, Miguel A. Figueroa-Villanueva wrote:
> On 11/27/07, clinton wrote:
> > On Saturday 24 November 2007 3:23:16 pm Miguel A. Figueroa-Villanueva wrote:
> > > Hello,
> > >
> > > I would like to propose the following patch or something similar to
> > > add support for moc compiler options. Currently, one can do the
> > > following:
> > >
> > > SET(moc-sources foo.h bar.h)
> > > QT4_WRAP_CPP(sources ${moc-sources})
> > >
> > > With the attached patch one could pass also options to be invoked with
> > > each moc-source:
> > >
> > > QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
> > >
> > > The current approach is a simplified one to support the following syntax:
> > >
> > > QT4_WRAP_CPP( [OPTIONS opt1 opt2 ...])
> > >
> > > This could also be applied to QT4_WRAP_UI(...).
> > >
> > > --Miguel
> >
> > I'm curious what the convention is for adding arguments to custom commands
> > in
> > macros.
>
> Don't know... But I looked at how cmake commands work and tried to
> provide something along those lines.
>
> > To compare, I see the FindSWIG.cmake/UseSWIG.cmake allow setting the
> > CMAKE_SWIG_FLAGS variable. The advantage of that is that it applies to all
> > calls of the macro.
>
> The problem I see with this is that you depend on the value of say
> QT4_MOC_FLAGS and then scoping issues come into play. For example, if
> you set this flag then in a later call you will have it affect that
> call unintentionally unless you clear it. It's then complicated when
> you consider INCLUDE files. So, my thoughts were to send the options
> to the macro every time you need them and not worry about the variable
> scope ramifications and other use cases.
>
> Just my two cents,
> --Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] installing generated files
On Nov 28, 2007 6:45 AM, Stefan Kögl <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
> > You need to know the names of the files that will be generated and
> > then INSTALL(FILES ...)
> > Typically I just have a hardwired list of root words, from which I
> > derive .cxx .hxx and whatever a doxygen suffix is. Here are some
> > helper routines. You're probably also going to want an
> > ADD_CUSTOM_COMMAND so you can specify file outputs, rather than having
> > to always run doxygen.
> >
>
> This is really cumbersomely. Then I have to know how doxygen determines the
> output file names, and update the "root list" by hand every time I create,
> rename, and remove a file or function.
>
> ADD_CUSTOM_TARGET(docs-doxygen ALL
> COMMAND ${DOXYGEN_EXECUTABLE} ${doxygen_BINARY_DIR}/Doxyfile
> DEPENDS ${doxygen_BINARY_DIR}/Doxyfile
> VERBATIM)
So now you're running this target every single time you build. Which
is why I told you to use ADD_CUSTOM_COMMAND, so there would actually
be some file dependencies, so you wouldn't have to build it every
time.
> INSTALL(CODE "
> FILE(GLOB DOXYGEN_OUTPUT ${doxygen_BINARY_DIR}/html/*)
> FILE(INSTALL DESTINATION ${PERTUBIS_DOC_PATH}/html TYPE FILE FILES
> \${DOXYGEN_OUTPUT})
> ")
>
> ##
>
> The "FILE(INSTALL " signature is still undocumented, but it works. Is this
> solution "future-proof"?
The INSTALL(FILES ...) signature is plenty documented in CMake 2.4.7,
and I think in some earlier 2.4.* also.
If there's such a thing as a public FILE(INSTALL ...) command, it is
not documented in CMake CVS. At first brush, I would think having
INSTALL(FILES ...) and FILE(INSTALL ...) would be a poor choice for a
public API.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] custom targets can't be used in different subdirectories?
Le 28 nov. 07 à 17:35, Gaëtan Lehmann a écrit : Hi, I'm currently trying to build a project organized in subdirectories. In all the subdirectories, several files are generated at build time (with an ADD_CUSTOM_COMMAND). In all the directories, a custom target depending on all the files generated in the subdirectory is created with ADD_CUSTOM_TARGET, so it should be easy to declare a dependancy on all those files in another subdirectory. During the build, things are all right until "make" try to build a file which depends on a custom target from another subdirectory. Here is an example: [EMAIL PROTECTED] build]$ LC_ALL=C make BaseSwig [ 0%] Built target VXLNumericsIdx make[3]: *** No rule to make target `VXLNumericsIdx', needed by `ClassIndex/wrap_ITKCommonBase.i'. Stop. make[2]: *** [Modules/Base/CMakeFiles/BaseSwig.dir/all] Error 2 make[1]: *** [Modules/Base/CMakeFiles/BaseSwig.dir/rule] Error 2 make: *** [BaseSwig] Error 2 VXLNumericsIdx is defined in one subdir, and BaseSwig in another on. "make" reports that the custom target "VXLNumericsIdx" is built (that's true), but the line after, it say it can't find that target. It seems definitively strange to me! I'm using cmake cvs 2007-10-24, and have seen the same behavior with cmake 2.4.5 Any idea about what can be wrong? I've just find my mistake, which has nothing to do with subdirectories, but which don't fully explain the cmake behavior though: I was trying to add the dependency to the custom target with the DEPENDS option of ADD_CUSTOM_COMMAND, while I should have used ADD_DEPENDENCIES (this one works fine). However, it's strange that, with the DEPENDS option, the target is built. IMHO, it would be less confusing if the custom target would not be built at all, instead of giving a quite inconsistent error message. Here is a short CMakeLists.txt to reproduce that behavior: PROJECT(toto) ADD_CUSTOM_TARGET(CustomTarget) ADD_CUSTOM_COMMAND( OUTPUT output COMMAND touch output DEPENDS CustomTarget ) ADD_CUSTOM_TARGET(CustomCommand DEPENDS output) and run "make CustomCommand". For the next ones with that problem, the right way to do things is: PROJECT(toto) ADD_CUSTOM_TARGET(CustomTarget) ADD_CUSTOM_COMMAND( OUTPUT output COMMAND touch output ) ADD_CUSTOM_TARGET(CustomCommand DEPENDS output) ADD_DEPENDENCIES(CustomCommand CustomTarget) Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr PGP.sig Description: Ceci est une signature électronique PGP ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 9:39 AM, Mike Jackson <[EMAIL PROTECTED]> wrote: > Ya know, if we took all the energy and time that has gone into > debating this issue and instead focused it on CMake dev we might > solve some problems a bit quicker. Not really. In terms of my personal energy, it was absolutely trivial to entertain this discussion so far. And as far as I'm concerned, such discussions are important before just leaping off in some direction that's expensive to pursue. But if you're ready to "just do something," by all means do it. There's a CMake lexical scoping paradigm just waiting to be implemented that we already had a long discussion about. I'm not talking about that because as far as I'm concerned, we already said what needed to be said. I do think Pau's idea about using a few special characters to distinguish variable name scope has merit, but I will let others debate the pros and cons of it. Frankly, I see it as a race between the supposed ease of improving the CMake language, and the demonstrated ease of slapping Lua into it. With provisios about whether we really want straight Lua; at present I don't, so I'm inclined towards more work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] custom targets can't be used in different subdirectories?
Hi, I'm currently trying to build a project organized in subdirectories. In all the subdirectories, several files are generated at build time (with an ADD_CUSTOM_COMMAND). In all the directories, a custom target depending on all the files generated in the subdirectory is created with ADD_CUSTOM_TARGET, so it should be easy to declare a dependancy on all those files in another subdirectory. During the build, things are all right until "make" try to build a file which depends on a custom target from another subdirectory. Here is an example: [EMAIL PROTECTED] build]$ LC_ALL=C make BaseSwig [ 0%] Built target VXLNumericsIdx make[3]: *** No rule to make target `VXLNumericsIdx', needed by `ClassIndex/wrap_ITKCommonBase.i'. Stop. make[2]: *** [Modules/Base/CMakeFiles/BaseSwig.dir/all] Error 2 make[1]: *** [Modules/Base/CMakeFiles/BaseSwig.dir/rule] Error 2 make: *** [BaseSwig] Error 2 VXLNumericsIdx is defined in one subdir, and BaseSwig in another on. "make" reports that the custom target "VXLNumericsIdx" is built (that's true), but the line after, it say it can't find that target. It seems definitively strange to me! I'm using cmake cvs 2007-10-24, and have seen the same behavior with cmake 2.4.5 Any idea about what can be wrong? Thanks, Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr PGP.sig Description: Ceci est une signature électronique PGP ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Documentation (CMake CVS)
I hand made a simple .adp file (attached) for the Qt assistant the other day, as an experiment. Ideally, it would be generated based on sections and/or commands in the html file, and done in the CMakeLists.txt file. Do you want to pick up where I left off? Clint Mike Jackson wrote: Has anyone started a QtAssistant version of the CMake Docs? I was thinking of spending some time trying a few things but I don't want to start something that is already done, or at least farther along than I am.. I built the cvs cmake this morning and nothing really jumped out at me as having been done. -- Mike Jackson imikejackson & gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake CMake CMake cmake.html ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake Documentation (CMake CVS)
Has anyone started a QtAssistant version of the CMake Docs? I was thinking of spending some time trying a few things but I don't want to start something that is already done, or at least farther along than I am.. I built the cvs cmake this morning and nothing really jumped out at me as having been done. -- Mike Jackson imikejackson & gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] global variable passing up via INTERNAL cache variable
On Nov 27, 2007, at 3:55 PM, Luigi CALORI wrote:
I encoundered the same problems and in the end used the horrible
hack to use a file where
append, clear it in the main file.
I think I saw a thread about this. Good to know in the future.
I did figure out a solution without involving a file. You use one
variable to build the result and use a second variable to store it.
MACRO(APPEND_VALUE VALUE)
SET(temp_value ${MY_VALUE_BUILD} ${VALUE})
SET(MY_VALUE_BUILD ${temp_value} CACHE INTERNAL "List of values")
ENDMACRO(APPEND_VALUE)
ADD_SUBDIRECTORY(subdir1)
ADD_SUBDIRECTORY(subdir2)
# Make a copy of the built value
SET(MY_VALUE ${MY_VALUE_BUILD} CACHE INTERNAL "List of values")
# Clear the built value for the next run of cmake
SET(MY_VALUE_BUILD "" CACHE INTERNAL "List of values")
This worked just great for my project. The issue really isn't about
macros and more about getting a true "global" variable. It looks
like this feature is in CVS cmake, but I can't move to that yet.
I agree is an annoying limitation of the language and, as well as
lack of scope in variables
pose problems in using macros
This actually hasn't bit me yet (thankfully). I agree with the
thread that more powerful variable scoping would be very useful.
A question for the other LUA thread: are these problem solved in
LUA wrapping?
That would be another good reason to add LUA scripting
This is OT, but I've been following that thread, and I wouldn't mind
CMake script being based on a different language, but I would want a
wholesale conversion (i.e. either use CMake script or Lua or
whatever, because allowing mixing would cause a legacy nightmare). I
don't want to have to deal with more than a single language.
In the end, I don't think Kitware will make the transition unless
there are very compelling reasons since it will involve converting
huge number of scripts and documentation.
James
On Tue, 27 Nov 2007 15:31:25 -0700, James Bigler said:
I got a hint that I could do this to set values that could be read by
the CMakeLists.txt file above:
MACRO(APPEND_VALUE VALUE)
SET(temp_value ${MY_VALUE} ${VALUE})
MESSAGE("temp_value = ${temp_value}")
SET(MY_VALUE ${temp_value} CACHE INTERNAL "List of values")
ENDMACRO(APPEND_VALUE)
I would then call APPEND_VALUE in sub directories.
Life was good until I noticed that subsequent calls of
cmake would
append to the list making it grow and grow. I could do an insert
only if the value didn't already exist, but that would prevent me
from having values disappear if they wouldn't have added themselves
(i.e. removing calls to APPEND_VALUE).
I tried adding this to the top level CMakeLists.txt before any of my
ADD_SUBDIRECTORY. The hope was that when CMake was called it would
clear the variable before adding stuff to it again.
SET(MY_VALUE "" CACHE INTERNAL "")
However this stopped the appending from happening. It looks like
every time it pops up from a directory it resets MY_VALUE to what was
in there before decending the directory. This behavior is different
from when the variable wasn't explicitly created in the top level
CMakeLists.txt file. Is this because the variable was created at the
top level CMake instead of down below?
Is there any way to reliably get information passed automatically
from subdirs? This seems like a fundamental capability, and I'm very
frustrated trying to figure out how to make this work.
I've attached a simple project that illustates the problem. Run with
cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Ya know, if we took all the energy and time that has gone into debating this issue and instead focused it on CMake dev we might solve some problems a bit quicker. Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
AW: [CMake] Creating librarys with different names from their targets.
Hi Josef, try this: add_library(Foo.Code source.cpp) set_target_properties(Foo.Code PROPERTIES OUTPUT_NAME Foo) It should create a target "Foo.Code" building a library "Foo.lib". Best regards, Gerhard -Ursprüngliche Nachricht- Gesendet: Mittwoch, 28. November 2007 13:53 An: cmake@cmake.org Betreff: [CMake] Creating librarys with different names from their targets. I've got a library which I want to build from a target which has a different name. Is there any way of doing this? If I do, ADD_LIBRARY(Foo source.cpp) this creates a target called 'Foo' which builds 'Foo.lib'. However I want the library 'Foo.lib' to be built from a target call 'Foo.Code'. Is this possible? (I've not explained the whole picture as it's more complicated than this). ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating librarys with different names from their targets.
cmake --help-command SET_TARGET_PROPERTIES and read about the "OUTPUT_NAME" target property... HTH, David On 11/28/07, Josef Karthauser <[EMAIL PROTECTED]> wrote: > > I've got a library which I want to build from a target which has a > different name. Is there any way of doing this? > > > > If I do, > > > > ADD_LIBRARY(Foo source.cpp) > > > > this creates a target called 'Foo' which builds 'Foo.lib'. However I want > the library 'Foo.lib' to be built from a target call 'Foo.Code'. Is this > possible? (I've not explained the whole picture as it's more complicated > than this). > > > > this > > ___ > 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] Creating librarys with different names from their targets.
I've got a library which I want to build from a target which has a different name. Is there any way of doing this? If I do, ADD_LIBRARY(Foo source.cpp) this creates a target called 'Foo' which builds 'Foo.lib'. However I want the library 'Foo.lib' to be built from a target call 'Foo.Code'. Is this possible? (I've not explained the whole picture as it's more complicated than this). this ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] installing generated files
I would think:
INSTALL(DIRECTORY )
would do it in one command without knowledge of the sub-structure of the
directory.
Is there something wrong with that approach?
It should be less error prone than gathering knowledge of doxygen output
just for specifying a bunch of install rules that essentially say "install
all the files under this directory using the same structure under that other
directory..."
HTH,
David
On 11/28/07, Stefan Kögl <[EMAIL PROTECTED]> wrote:
>
> Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
> > You need to know the names of the files that will be generated and
> > then INSTALL(FILES ...)
> > Typically I just have a hardwired list of root words, from which I
> > derive .cxx .hxx and whatever a doxygen suffix is. Here are some
> > helper routines. You're probably also going to want an
> > ADD_CUSTOM_COMMAND so you can specify file outputs, rather than having
> > to always run doxygen.
> >
>
> This is really cumbersomely. Then I have to know how doxygen determines
> the
> output file names, and update the "root list" by hand every time I create,
> rename, and remove a file or function.
>
> After googling one more time I found this solution.
>
> http://www.cmake.org/pipermail/cmake/2007-January/012775.html
>
> ###
> new CMakeLists.txt
> ###
>
> PROJECT(doxygen)
> FIND_PACKAGE(Doxygen REQUIRED)
>
> CONFIGURE_FILE(${doxygen_SOURCE_DIR}/Doxyfile.in
> ${doxygen_BINARY_DIR}/Doxyfile)
>
> FILE(MAKE_DIRECTORY ${doxygen_BINARY_DIR})
>
> ADD_CUSTOM_TARGET(docs-doxygen ALL
> COMMAND ${DOXYGEN_EXECUTABLE} ${doxygen_BINARY_DIR}/Doxyfile
> DEPENDS ${doxygen_BINARY_DIR}/Doxyfile
> VERBATIM)
>
> INSTALL(CODE "
> FILE(GLOB DOXYGEN_OUTPUT ${doxygen_BINARY_DIR}/html/*)
> FILE(INSTALL DESTINATION ${PERTUBIS_DOC_PATH}/html TYPE FILE FILES
> \${DOXYGEN_OUTPUT})
> ")
>
> ##
>
> The "FILE(INSTALL " signature is still undocumented, but it works. Is
> this
> solution "future-proof"?
>
> ___
> 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] installing generated files
Am Mittwoch, 28. November 2007 10:38:20 schrieb Brandon Van Every:
> You need to know the names of the files that will be generated and
> then INSTALL(FILES ...)
> Typically I just have a hardwired list of root words, from which I
> derive .cxx .hxx and whatever a doxygen suffix is. Here are some
> helper routines. You're probably also going to want an
> ADD_CUSTOM_COMMAND so you can specify file outputs, rather than having
> to always run doxygen.
>
This is really cumbersomely. Then I have to know how doxygen determines the
output file names, and update the "root list" by hand every time I create,
rename, and remove a file or function.
After googling one more time I found this solution.
http://www.cmake.org/pipermail/cmake/2007-January/012775.html
###
new CMakeLists.txt
###
PROJECT(doxygen)
FIND_PACKAGE(Doxygen REQUIRED)
CONFIGURE_FILE(${doxygen_SOURCE_DIR}/Doxyfile.in
${doxygen_BINARY_DIR}/Doxyfile)
FILE(MAKE_DIRECTORY ${doxygen_BINARY_DIR})
ADD_CUSTOM_TARGET(docs-doxygen ALL
COMMAND ${DOXYGEN_EXECUTABLE} ${doxygen_BINARY_DIR}/Doxyfile
DEPENDS ${doxygen_BINARY_DIR}/Doxyfile
VERBATIM)
INSTALL(CODE "
FILE(GLOB DOXYGEN_OUTPUT ${doxygen_BINARY_DIR}/html/*)
FILE(INSTALL DESTINATION ${PERTUBIS_DOC_PATH}/html TYPE FILE FILES
\${DOXYGEN_OUTPUT})
")
##
The "FILE(INSTALL " signature is still undocumented, but it works. Is this
solution "future-proof"?
signature.asc
Description: This is a digitally signed message part.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Variable scoping (was Re: [CMake] CMake with Lua Experiment)
Quoting Brandon Van Every <[EMAIL PROTECTED]>: On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html "These are not the threads you're looking for." If you are talking about a different thread, could you please tell me which one? "lexical scoping" http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords "lexical scoping." Most baffling since it's the subject line. Wow. I did not read a single message in that thread. I would have suggested inlining the scope of the variable in the variable name, like Ruby does, instead of SET, SET(LOCAL ...), VARIABLE_SCOPE, etc: * variable => local variable * @variable => instance variable * @@variable => class variable * $variable => global variable * VARIABLE => constant Of course it would be different in CMake. Here comes a quick'n'dirty proposal: * variable => global variable (keep compatibility with CMake 2.4) * @variable => local variable (for example, inside a macro, if, foreach, etc) * @@variable => module (= file) variable (for instance, for Find.cmake modules). It does not exist outside the current file (even INCLUDE'ing a file which defines @@variable would NOT make @@variable available outside the file which defined it). * VARIABLE => constants defined by modules (Find.cmake), cannot be changed after setting it (this way it's impossible to accidentally modify for example QT_LIBRARIES in a CMakeLists.txt) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] installing generated files
You need to know the names of the files that will be generated and
then INSTALL(FILES ...)
Typically I just have a hardwired list of root words, from which I
derive .cxx .hxx and whatever a doxygen suffix is. Here are some
helper routines. You're probably also going to want an
ADD_CUSTOM_COMMAND so you can specify file outputs, rather than having
to always run doxygen.
MACRO(ADD_SUFFIX rootlist suffix)
SET(outlist)
FOREACH(root ${${rootlist}})
LIST(APPEND outlist ${root}${suffix})
ENDFOREACH(root)
SET(${rootlist} ${outlist})
ENDMACRO(ADD_SUFFIX)
MACRO(ADD_PREFIX prefix rootlist)
SET(outlist)
FOREACH(root ${${rootlist}})
LIST(APPEND outlist ${prefix}${root})
ENDFOREACH(root)
SET(${rootlist} ${outlist})
ENDMACRO(ADD_PREFIX)
Cheers,
Brandon Van Every
On Nov 28, 2007 1:25 AM, Stefan Kögl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> how to install files generated by custom targets, eg. doxygen? The files are
> generated in ${DOXYGEN_BINARY_DIR}/html ( /doc/html ).
>
> here is the /doc/CMakeLists.txt
> ##
>
> PROJECT(doxygen)
> FIND_PACKAGE(Doxygen REQUIRED)
>
> CONFIGURE_FILE(${doxygen_SOURCE_DIR}/Doxyfile.in
> ${doxygen_BINARY_DIR}/Doxyfile)
>
> FILE(MAKE_DIRECTORY ${doxygen_BINARY_DIR}/html)
> ADD_CUSTOM_TARGET(docs-doxygen COMMAND ${DOXYGEN_EXECUTABLE}
> ${doxygen_BINARY_DIR}/Doxyfile VERBATIM)
> INSTALL(DIRECTORY ${doxygen_BINARY_DIR}/html DESTINATION ${PERTUBIS_DOC_PATH})
>
> ##
>
> Stefan Kögl
>
> ___
> 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] CMake with Lua Experiment
On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: > > Do you mean these threads? > http://www.cmake.org/pipermail/cmake/2005-March/006235.html > http://www.cmake.org/pipermail/cmake/2005-June/006725.html "These are not the threads you're looking for." > If you are talking about a different thread, could you > please tell me which one? "lexical scoping" http://public.kitware.com/pipermail/cmake/2007-November/017385.html Must say, I couldn't find this by using the Kitware mailing list search engine on the keywords "lexical scoping." Most baffling since it's the subject line. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:20 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > I'd also like a shorter way to dereference a table than > > unpack(table). > > Seriously, this is a total non-issue and unpack is totally unnecessary. The argument evaluation model matters. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:17 AM, E. Wing <[EMAIL PROTECTED]> wrote: > > Right now I think it's just an experiment to see how things might > work, how much effort would be involved, and how much of an impedance > mismatch there will be with how things are currently done. It sounds > like things may not progress any further unless a real long term > vision for CMake is developed and embraced. Gee you want one of those? :-) Here's one: happy, shiny programmers using a happy, shiny, fullblown programming language to implement entire build systems with little or no reference to external Perl, Python, or Ruby code. People wouldn't have much need for those if CMake's language features were sufficient. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:59 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > For any given CMake function, we know what argument types we expect. > The programmer is responsible for dereferencing, we're not going to do > it for them. We just have to parse the keywords like STATIC, and pay > attention to fixed positions at the beginning of an argument list. In > fact, come to think of it, "if it's a CMake reserved function, hand it > off to a special argument processor," would solve much of the problem. > Then you're just down to changing Lua table constructors, so that > they don't require quotes. Unfortunately it has to work for user created functions also, so I guess it's not quite so simple. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 3:13 AM, E. Wing <[EMAIL PROTECTED]> wrote:
> > (Aside: what's with the cm_ prefix?)
>
> Often
> when I have to read other people's code, I can't distinguish between
> the 'official' API functions are and the userland functions when I do
> not know the official API very well.
Yeah but that's your fault. :-) Do enough CMake and you're gonna
know that add_library isn't something anyone made up. I will admit
that a few of the uncommon functions could throw me. Like site_name,
which I only learned the other day after 2 years of hardcore staring
at CMake all the time. But I looked it up no big deal, right?
Furthermore, the CMake 2.6 docs have a better breakdown, there's a
"CMake Commands Only" section with a HTML index. These are separate
from the standard modules, which now have their own section. Module
names are exceedingly verbose, you're not going to mistake them. So
it's trivial to learn the reserved commands, there's maybe ~60 of
them, all concisely indexed in one place. The depreciated commands
have been moved out, thinning the ranks.
> >> As I said, the use of unpack() was
> > > unnecessary.
> >
> > I'm doubting that's correct. I doubt that sources and unpack(sources)
> > are the same thing at all.
>
> So you're not listening. What I said is:
>
> In both cases, the function cm_add_library receive 5 strings as arguments.
No, we're talking past each other. I said I figured it out after
reading the docs for 15 minutes. I was saying, in a long-winded
manner, that CMake script's ${list} is equivalent to Lua's
unpack(table), and that CMake is less verbose than Lua for list/table
dereferencing. Since this is an operation that I do all the friggin'
time in 1/2 the lines of code I write, I consider it important.
> I'm also saying that is it easy to implement cm_add_library so you can
> handle the above case (the vararg case) but you can also handle the
> case where the user does:
>
> cm_add_library( "simpleLib", "STATIC", sources)
And I think rewriting all the CMake functions to dereference
lists/tables on the user's behalf is busywork. Nor do I, as a
programmer, want my lists/tables automagically dereferenced. When
it's my turn to write standard modules, macros, or functions, I want
clear expectations about who's gonna do the work. What the expected
type of input is, and what an error is.
> > What we really want is Ruby without the licensing hassles. And a bit
> > faster.
>
>
> Well, not really. Embedding Ruby (or Python) is a lot harder than
> embedding Lua.
And a bit smaller.
> As far as Ruby syntax is concerned, I don't see how it is
> significantly different than Lua.
And a bit more PCRE. Lua's inherent regexes are weird.
> All the Ruby code I've seen also has
> quotes around string literals and commas separating items in lists.
Ok my bad. I keep thinking of Ruby as "souped up Perl." Seems like
Perl, Make, CMake, and various shells are the sane ones as far as
string entry.
> As for marketing, I can't predict the future. Any language is subject
> to these whims. We could all be writing in Lisp some day.
Ain't gonna happen. The market has spoken: Lisp is weird. People
will use it, and its use may even increase, but it's never going to be
a majority language. Rather, the majority languages will steal Lisp
features and make them less weird.
> One thing to be aware of though. Notice strings are quotes, but
> variables are not (like C/C++). So an ambiguity problem may be
> created. So if I were to do something like:
>
> myLibraryName = "simpleLib"
> listOfFilesFound = cm_file(GLOB, "*.c") -- wrapper around CMake FILE,
> but utilizes return parameter
> cm_add_library(myLibraryName, STATIC, listOfFilesFound)
>
> Notice that all the quotes are gone by the cm_add_library command
> because everything was somehow placed into a variable.
But that's wrong. Should be
add_library(myLibraryName, STATIC, ${listOfFilesFound})
where of course we've implemented ${} instead of unpack() ;-)
For any given CMake function, we know what argument types we expect.
The programmer is responsible for dereferencing, we're not going to do
it for them. We just have to parse the keywords like STATIC, and pay
attention to fixed positions at the beginning of an argument list. In
fact, come to think of it, "if it's a CMake reserved function, hand it
off to a special argument processor," would solve much of the problem.
Then you're just down to changing Lua table constructors, so that
they don't require quotes.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Quoting Brandon Van Every <[EMAIL PROTECTED]>: Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get "for free," whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Do you mean these threads? http://www.cmake.org/pipermail/cmake/2005-March/006235.html http://www.cmake.org/pipermail/cmake/2005-June/006725.html If that is so, yes, I guess I missed them (I was not using CMake back then :-). If you are talking about a different thread, could you please tell me which one? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
> I'd also like a shorter way to dereference a table than > unpack(table). Seriously, this is a total non-issue and unpack is totally unnecessary. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
> Is backward compatibility with the current language a goal of the LUA > experiment? I ask because the examples spoken of on this list appear to be > trying to mimic the current CMake syntax. Right now I think it's just an experiment to see how things might work, how much effort would be involved, and how much of an impedance mismatch there will be with how things are currently done. It sounds like things may not progress any further unless a real long term vision for CMake is developed and embraced. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
> (Aside: what's with the cm_ prefix?)
The cm_ prefix was something Ken put in his demo. I assumed he was
trying to 'namespace' the thing. I personally like the idea and really
think it should have been applied to the regular CMake language. Often
when I have to read other people's code, I can't distinguish between
the 'official' API functions are and the userland functions when I do
not know the official API very well. I certainly had this problem with
CMake when I first started out, and I also have this problem with
CMake functions that I forget about or don't know about either due to
legacy redundancy/obsoletion or new things introduced.
>> As I said, the use of unpack() was
> > unnecessary.
>
> I'm doubting that's correct. I doubt that sources and unpack(sources)
> are the same thing at all.
So you're not listening. What I said is:
cm_add_library( "simpleLib", "STATIC", "simpleLib.cxx",
"simpleCLib.c", "simpleWe.cpp")
is identical to:
sources = {"simpleLib.cxx", "simpleCLib.c", "simpleWe.cpp"}
cm_add_library( "simpleLib", "STATIC", unpack(sources))
In both cases, the function cm_add_library receive 5 strings as arguments.
I'm also saying that is it easy to implement cm_add_library so you can
handle the above case (the vararg case) but you can also handle the
case where the user does:
cm_add_library( "simpleLib", "STATIC", sources)
In this case, cm_add_library receives 2 string arguments and 1 table
argument. The implementation of cm_add_library can be easily written
to handle both cases so the CMake scripter can write whatever seems
most natural to them. This makes the need for unpack() unnecessary.
> Yes I know. I was saying that passing "file1.c file2.c file3.c" is
> not a solution to Lua's excessive quoting problem, because you'd be
> sacrificing desireable processing capabilities. We want to be able to
> operate on lists/tables of stuff with FOREACH, LIST, individuated
> parameters, and so forth.
I'm not understanding what you're getting at. But I think this is
probably much ado about nothing. Once you get your files into a table,
you can do all your expected foreach/list stuff. There won't be any
excessive quoting here. I don't see any reason while the CMake FOREACH
couldn't also be exposed through a Lua API either so you should be
able to use which ever fits best.
>
> The point is that the marketing luster of Lua will fade. The legacy
> CMake builds will all be using an old, hoary version of Lua. CMake
> will have to support those old builds to some degree. It won't be
> able to utilize newfangled Lua stuff, if the newfangled stuff breaks
> backwards compatibility. I bet there are problems between Python
> 1.5.2 and 2.5.1, although I'm not up on them. I bet the Python
> community doesn't consider Python 1.5.2 a sales point, if they stare
> closely at SCons. Now, people may not stare closely. And in any
> event, the luster of Lua will probably last 5 years. But then it'll
> be over, and the real question will be, was it a cool choice for text
> processing? 'Cuz that's what a build system mostly is.
>
> What we really want is Ruby without the licensing hassles. And a bit
> faster.
Well, not really. Embedding Ruby (or Python) is a lot harder than
embedding Lua. There are very few languages that focus specifically on
this niche. Most languages want to be the end-all and offer great
libraries to easily build certain types of things (Rails, Twisted).
Lua's focus is embedding which is why it is a great tool for this
specific kind of job with regards to CMake.
As far as Ruby syntax is concerned, I don't see how it is
significantly different than Lua. All the Ruby code I've seen also has
quotes around string literals and commas separating items in lists.
But I wouldn't worry much about the speed of Ruby. Most of the
performance bottlenecks will be within CMake itself doing the heavy
lifting and file I/O. It's just nice that with Lua, you don't have to
fend off detractors on the speed argument so much. But I don't see it
as a real problem.
As for marketing, I can't predict the future. Any language is subject
to these whims. We could all be writing in Lisp some day. However, Lua
has been around for awhile (it's older than Java) and I don't expect
it to disappear. And adoption of Lua has been driven more by the fact
that it's a really good tool for solving specific sets of problems,
not so much marketing. (It's just interesting that World of Warcraft
has suddenly changed the marketing aspect because the game is so
huge.) I can say with some certainty that even if the marketing loses
its luster, it will still be an easier sale than marketing CMake's
proprietary language.
> > cm_add_library( "simpleLib", STATIC, sources)
>
> That's an improvement.
>
> I wish we could get rid of quotes in places that don't need them. How
> easy would it be to modify Lua in that regard? So, CMake would be a
> Lua variant rather than straight Lua.
> cm_add_library( "simpleLib", STATIC
Re: [CMake] CMake with Lua Experiment
On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote: > > As "DSL based on Lua" != Lua, assuming Kitware gets rid of > documentation and bugs in the language might be too optimistic. Look > for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based > DSL for hardware description, like Verilog or VHDL, but it's so > different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. > Talking about Ruby, could someone please paste his wishlist about > variable scoping for CMake? (ie what would you like to add: local > variables which die when you exit the loop, file-scoped variables, > directory-scoped variables, project-scoped variables, what?). It's > quite difficult to fix a problem we have not properly defined (at > least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get "for free," whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. We already had the extended discussion about possible CMake scope implementations, so I'm not understanding what you're asking. I assumed that Kitware is ready to act when they have time to do so. Did you miss that discussion? Did it leave you with a bunch of unresolved questions? If so, I'd suggest going back into the archive and responding to specific things you're unclear about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
