[CMake] Building linux kernel module with Cmake
Hi All, I am a newbie with cmake and am trying to build a Linux device driver with this utility. I have tried this utility with building applications. It works fine. But, I am not able to compile the kernel modules. I have a makefile for this driver which uses KBuild for compiling the driver and generates a .ko file. Can anybody please help me? Thanks in advance ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
On Wednesday 31 October 2007, Jesper Eskilson wrote:
Bill Hoffman wrote:
For this case, you could have something like this:
# if SOME_PROGRAM has a value but the program has been moved
# or removed from the system, then clear the cache entry
# so that find_program will try again.
if(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
set(SOME_PROGRAM NOTFOUND CACHE FORCE some program)
endif(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
find_program(SOME_PROGRAM myprog)
So, if you know that you are changing a cmakelist file in a way that
requires something to be removed from the cache, just remove it, but be
careful not to remove it all the time.
Ouch. My cmake files are unreadable enough without an added 3 lines here
and there checking if the cache entry needs to be replaced or not.
With cmake cvs you could run cmake -USOME_PROGRAM dir which would remove
the variable SOME_PROGRAM from the cache first and then run cmake.
But I guess that's no acceptable solution for MSVC users.
BTW: Are there any plans of fixing the broken regeneration for Visual
Studio? Or at least documenting it as known problem? As it is now, the
project files are regenerated but not reloaded, and there is no feedback
that the new project files aren't used for the build.
I really think this should be filed as a bug report/support issue/whatever the
right way is to MS, so that they at least know about that (no matter whether
they will find it worthwhile to fix something which will help writing
portable software).
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Andreas Pakulat wrote: On Mittwoch, 31. Oktober 2007, Jesper Eskilson wrote: BTW: Are there any plans of fixing the broken regeneration for Visual Studio? Or at least documenting it as known problem? As it is now, the project files are regenerated but not reloaded, and there is no feedback that the new project files aren't used for the build. How exactly should cmake fix a bug in Visual Studio? As far as I understood this thread the problem is that VS doesn't get that its project files have changed and thus doesn't reload them. I suggest to contact your MS support contact. Visual Studio *does* reload the project files, but not *during* a build. If any project files are modified during a build, they are reloaded *after* the build is complete. I'm not sure if I would call this a bug, even if it conjunction with cmake causes a breakage when cmake tries to regenereate project files. In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Building linux kernel module with Cmake
Thanks for you reply Hendrik Even I know that Kbuild is a very simple procedure to do so. But I have a source tree which has applications, drivers and other modules for different OS as well as hardware architectures and I want to compile all these folders from a single top level directory. All this can be achieved with Cmake utlity. I have already compiled other modules. I want to know if it possible to use cmake for compiling kernel module -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hendrik Sattler Sent: Thursday, November 01, 2007 3:00 PM To: cmake@cmake.org Subject: Re: [CMake] Building linux kernel module with Cmake Am Donnerstag 01 November 2007 schrieb Suhas Jain: I am a newbie with cmake and am trying to build a Linux device driver with this utility. I have tried this utility with building applications. It works fine. But, I am not able to compile the kernel modules. I have a makefile for this driver which uses KBuild for compiling the driver and generates a .ko file. Can anybody please help me? I don't see the point using cmake for such a task. Using Kbuild with a _very_ short Makefile (that never changes) and one Kbuild file, it's already simple enough. There is also no cross-platform support needed (it's going to be a linux kernel module anyway). HS ___ 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] Building linux kernel module with Cmake
Am Donnerstag 01 November 2007 schrieb Suhas Jain: I am a newbie with cmake and am trying to build a Linux device driver with this utility. I have tried this utility with building applications. It works fine. But, I am not able to compile the kernel modules. I have a makefile for this driver which uses KBuild for compiling the driver and generates a .ko file. Can anybody please help me? I don't see the point using cmake for such a task. Using Kbuild with a _very_ short Makefile (that never changes) and one Kbuild file, it's already simple enough. There is also no cross-platform support needed (it's going to be a linux kernel module anyway). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Make clean - doesn't clean dependencies.
It doesn't appear that a 'make clean' in a subdirectory of the build tree cleans any of the dependencies. Does anyone know of a way that it can be persuaded to? Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
On 01.11.07 10:49:12, Jesper Eskilson wrote: In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. So far you're the only one claiming that (in this thread), I suggest to come up with a small sample project where changing the CMakeLists.txt doesn't trigger a cmake run. If you've got that you can file a bugreport against cmake. Andreas -- You are a bundle of energy, always on the go. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Link directories order
Hello, I'm having trouble with cmake LINK_DIRECTORIES order. I understand cmake smart-orders link directory flags. However, flags coming from the shell env LDFLAGS don't seem to be taken into account in this smart sort. Is this a feature or a bug? To illustrate the issue, I slightly modified the example code from http://www.cmake.org/HTML/cmakeExample.tar.gz The only change is in cmakeExample.tar.gz:CMakeExample/Hello/CMakeLists.txt which becomes # Create a library called Hello which includes the source file hello.cxx. # The extension is already found. Any number of sources could be listed here. add_library (Hello hello.cxx) INSTALL(TARGETS Hello RUNTIME DESTINATION bin ARCHIVE DESTINATION lib LIBRARY DESTINATION lib) As one can see in the attached terminal output, the linker for Demo looks in /tmp/lib before looking in the build dir: /usr/bin/c++ -headerpad_max_install_names -fPIC -L/tmp/lib CMakeFiles/helloDemo.dir/demo.o CMakeFiles/helloDemo.dir/demo_b.o -o helloDemo -L/Volumes/Data/Users/detryr/tmp/CMakeExample/Hello -lHello As a result, Demo is linked against an obsolete installed version of Hello, instead of the local fresh one. Note that /tmp/lib was empty when I ran cmake. Cheers, Renaud. [EMAIL PROTECTED] $ export LDFLAGS=-L/tmp/lib [~/tmp/ CMakeExample] [EMAIL PROTECTED] $ rm /tmp/lib/libHello.a [~/tmp/ CMakeExample] rm: /tmp/lib/libHello.a: No such file or directory [EMAIL PROTECTED] $ cmake -DCMAKE_INSTALL_PREFIX=/tmp [~/tmp/ CMakeExample] -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Configuring done -- Generating done -- Build files have been written to: /Volumes/Data/Users/detryr/tmp/ CMakeExample [EMAIL PROTECTED] $ make VERBOSE=1 [~/tmp/ CMakeExample] /usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -H/Volumes/Data/ Users/detryr/tmp/CMakeExample -B/Volumes/Data/Users/detryr/tmp/ CMakeExample --check-build-system CMakeFiles/Makefile.cmake 0 Clearing dependencies in Hello/CMakeFiles/Hello.dir/depend.make. Clearing dependencies in Hello/CMakeFiles/Hello.dir/depend.internal. Clearing dependencies in Demo/CMakeFiles/helloDemo.dir/depend.make. Clearing dependencies in Demo/CMakeFiles/helloDemo.dir/ depend.internal. /usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_progress_start /Volumes/Data/Users/detryr/tmp/CMakeExample/ CMakeFiles 3 make -f CMakeFiles/Makefile2 all make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ Hello.dir/depend Scanning dependencies of target Hello cd /Volumes/Data/Users/detryr/tmp/CMakeExample /usr/local/ cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_depends Unix Makefiles /Volumes/Data/Users/detryr/tmp/CMakeExample /Volumes/Data/ Users/detryr/tmp/CMakeExample/Hello /Volumes/Data/Users/detryr/tmp/ CMakeExample /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello / Volumes/Data/Users/detryr/tmp/CMakeExample/Hello/CMakeFiles/Hello.dir/ DependInfo.cmake make -f Hello/CMakeFiles/Hello.dir/build.make Hello/CMakeFiles/ Hello.dir/build /usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ CMakeFiles 1 [ 33%] Building CXX object Hello/CMakeFiles/Hello.dir/hello.o /usr/bin/c++-o Hello/CMakeFiles/Hello.dir/hello.o -c /Volumes/ Data/Users/detryr/tmp/CMakeExample/Hello/hello.cxx Linking CXX static library libHello.a cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello /usr/local/ cmake-2.4.7-Darwin-universal/bin/cmake -P CMakeFiles/Hello.dir/ cmake_clean_target.cmake cd /Volumes/Data/Users/detryr/tmp/CMakeExample/Hello /usr/local/ cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_link_script CMakeFiles/Hello.dir/link.txt --verbose=1 /usr/bin/ar cr libHello.a CMakeFiles/Hello.dir/hello.o /usr/bin/ranlib libHello.a /usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ CMakeFiles 1 [ 33%] Built target Hello make -f Demo/CMakeFiles/helloDemo.dir/build.make Demo/CMakeFiles/ helloDemo.dir/depend Scanning dependencies of target helloDemo cd /Volumes/Data/Users/detryr/tmp/CMakeExample /usr/local/ cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_depends Unix Makefiles /Volumes/Data/Users/detryr/tmp/CMakeExample /Volumes/Data/ Users/detryr/tmp/CMakeExample/Demo /Volumes/Data/Users/detryr/tmp/ CMakeExample /Volumes/Data/Users/detryr/tmp/CMakeExample/Demo / Volumes/Data/Users/detryr/tmp/CMakeExample/Demo/CMakeFiles/ helloDemo.dir/DependInfo.cmake make -f Demo/CMakeFiles/helloDemo.dir/build.make Demo/CMakeFiles/ helloDemo.dir/build /usr/local/cmake-2.4.7-Darwin-universal/bin/cmake -E cmake_progress_report /Volumes/Data/Users/detryr/tmp/CMakeExample/ CMakeFiles 2 [
[CMake] CPPFLAGS
Hello, CMake takes many variables from the shell env (CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, ...) but CPPFLAGS seems to be ignored, forcing -Iinclude dir in CFLAGS/CXXFLAGS. I'm using cmake-2.4.7-Darwin-universal. Is this intentional? Thanks, Renaud. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CONFIGURE_FILE list substitutions
Hello, My package has a package.pc.in pkg-config template that is used to create package.pc using CONFIGURE_FILE. In the pc.in file I have this line: Requires: @PKG_DEPS@ and in my CMakeLists.txt I have SET(PGK_DEPS boost libxml) The problem is that the output becomes Requires: boost;libxml and I want the list space-separated not semi-colon separated. How can I fix this? Regards, Thomas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Andreas Pakulat wrote: On 01.11.07 10:49:12, Jesper Eskilson wrote: In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. So far you're the only one claiming that (in this thread), I suggest to come up with a small sample project where changing the CMakeLists.txt doesn't trigger a cmake run. If you've got that you can file a bugreport against cmake. Did you actually read my post before replying? I'm not claiming that cmake does not regenerate the project files. I'm not claiming that Visual Studio does not reload the projects files. What I'm claiming is that ***the project files aren't reloaded until the build already has completed***, meaning that I need to build ***again*** to make sure that the changes to my CMakeLists.txt actually make it into Visual Studio. This can be demonstrated with the most trivial of CMakeLists.txt files: --- project(foo) add_executable(foo foo.c) --- 1. Run CMake 2. Open solution in Visual Studio 3. Build 4. Add a file, say bar.c, to the CMakeLists.txt file 5. Build (this triggeres a cmake rebuild) 6. Build completes, but bar.c is NOT included in the build. 7. Visual Studio asks if I want to reload the project files I don't think I can make myself clearer than this. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
On Nov 1, 2007, at 7:29 AM, Jesper Eskilson wrote: Andreas Pakulat wrote: On 01.11.07 10:49:12, Jesper Eskilson wrote: In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. So far you're the only one claiming that (in this thread), I suggest to come up with a small sample project where changing the CMakeLists.txt doesn't trigger a cmake run. If you've got that you can file a bugreport against cmake. Did you actually read my post before replying? I'm not claiming that cmake does not regenerate the project files. I'm not claiming that Visual Studio does not reload the projects files. What I'm claiming is that ***the project files aren't reloaded until the build already has completed***, meaning that I need to build ***again*** to make sure that the changes to my CMakeLists.txt actually make it into Visual Studio. What is the desired behavior? Did you want CMake to somehow notify the user that your project build is incomplete and to build again? Did you want CMake to stop after rebuilding project files, notify the user, then only build the code if the project files weren't modified? James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Fixed : RE: [CMake] Make clean - doesn't clean dependencies.
Sent: 01 November 2007 10:59 It doesn't appear that a 'make clean' in a subdirectory of the build tree cleans any of the dependencies. Does anyone know of a way that it can be persuaded to? I've fixed it, see the attached patch. (I'll also submit this as a bug). Joe fix_clean.patch Description: fix_clean.patch ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Universal Binary Support on OS X 10.4
I am on a MacBook Pro and need to compile for PPC. I launch ccmake and set CMAKE_OSX_ARCHITECTURES to ppc. I then generate and then run make VERBOSE=1. What gets produced is still an i386 binary though. If I manually put in -arch ppc into both the c and c++ compile flags then I get a ppc build. Is this the way it is supposed to work or am I missing something. -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Default Debug format for OS X 10.5 Leopard
Apple has moved to using dwarf as its default debugging format. Is there support going into cmake to set this as the default debug argument string? -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Copyonly symlink ?
Hi, With the CONFIGURE_FILES( ... COPYONLY ) command, is it possible to make a symlink to the file on system that supports symlink and really copy the file on system that doesn't support symlink ? If not, is there another way to do this ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Copyonly symlink ?
On Nov 1, 2007 11:31 AM, Félix C. Morency [EMAIL PROTECTED] wrote: Hi, With the CONFIGURE_FILES( ... COPYONLY ) command, is it possible to make a symlink to the file on system that supports symlink and really copy the file on system that doesn't support symlink ? I don't think so. If not, is there another way to do this ? Try the cmake -E commands. Cheers, Brandon Van Ever ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
On 11/1/07, Jesper Eskilson [EMAIL PROTECTED] wrote: KSpam wrote: If you run the ZERO_CHECK target, CMake will generate the new project files without building everything. Following ZERO_CHECK, Visual Studio would have to reload the projects, and then you could build like normal. This makes building in Visual Studio essentially a two-step process. Good to know. I'll relay this to my users; I think many of them use a rather convoluted way of running CMake outside of Visual Studio. Jesper, Maybe this is a good addition to the FAQ or somewhere else in the wiki as it seems to be a limitation that is not soon to be solved since it really requires MS Visual Studio to act upon it. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
re: [CMake] disabling the cache
On Nov 1, 2007 2:27 PM, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED] wrote: On 11/1/07, Jesper Eskilson [EMAIL PROTECTED] wrote: KSpam wrote: If you run the ZERO_CHECK target, CMake will generate the new project files without building everything. Following ZERO_CHECK, Visual Studio would have to reload the projects, and then you could build like normal. This makes building in Visual Studio essentially a two-step process. Good to know. I'll relay this to my users; I think many of them use a rather convoluted way of running CMake outside of Visual Studio. Jesper, Maybe this is a good addition to the FAQ or somewhere else in the wiki as it seems to be a limitation that is not soon to be solved since it really requires MS Visual Studio to act upon it. I'll make my usual plea not to overburden the FAQ with every issue that anyone could ever conceive. I would suggest adding a Visual Studio section to http://www.cmake.org/Wiki/CMake_Platform_Dependent_Issues . Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building linux kernel module with Cmake
On Nov 1, 2007 5:48 AM, Suhas Jain [EMAIL PROTECTED] wrote: Thanks for you reply Hendrik Even I know that Kbuild is a very simple procedure to do so. But I have a source tree which has applications, drivers and other modules for different OS as well as hardware architectures and I want to compile all these folders from a single top level directory. All this can be achieved with Cmake utlity. I have already compiled other modules. I want to know if it possible to use cmake for compiling kernel module It would be simpler to use ADD_CUSTOM_COMMAND / ADD_CUSTOM_TARGET to invoke the Linux kernel's native Kbuild, then utilize the results. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Default Debug format for OS X 10.5 Leopard
On 11/1/07 10:39 AM, Mike Jackson said: Apple has moved to using dwarf as its default debugging format. Is there support going into cmake to set this as the default debug argument string? By default CMake sets CMAKE_C_FLAGS_DEBUG to include -g. On 10.4, - g means 'stabs' and you have to pass '-gdwarf-2' to get dwarf. But in 10.5, -g means dwarf. So I think CMake is correct in just using -g always, don't you? -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Make clean - doesn't clean dependencies.
Josef Karthauser wrote: It doesn’t appear that a ‘make clean’ in a subdirectory of the build tree cleans any of the dependencies. Does anyone know of a way that it can be persuaded to? make depend For more info, cmake creates: make help -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] regex ^ does not anchor against the original string
^ doesn't anchor against the original input string. It anchors
against the string as it is processed! If replacements cause the
string to have a new beginning, it anchors against the new beginning.
I want to say that's a bug. Do other regex gurus agree, or have I
just not gone up the learning curve sufficiently?
SET(problem else else else else else)
MESSAGE(original string:)
MESSAGE(${problem})
MESSAGE(expecting replacement to have 4 else's. Instead we get:)
STRING(REGEX REPLACE
^.else
out ${problem})
MESSAGE(${out})
C:\devel\mozcmake -P sideeffect.cmake
original string:
else else else else else
expecting replacement to have 4 else's. Instead we get:
C:\devel\moz
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] improve the CMake language?
Recently I've been doing a non-trivial amount of programming in CMake script. When I started my current project I thought it would be a quick throwaway, but it has ballooned into a substantial body of code with a call structure about 3 routines deep. I've started to feel the pinch of MACRO variables shadowing each other. I find myself writing long variable names out of paranoia that they'll collide. I've had some bugs due to that, so it's not groundless paranoia. It's making the code a lot less readable, not to mention being more tedious to type. I've made note of escape problems when passing literal strings to MACROs, as have others. I've discovered regex bugs. I've also had plenty of regex misunderstandings that were not bugs, because there's no documentation for all the behavioral corner cases. Is it worth trying to address these problems and make CMake a better scripting language? Currently I'd have to tell people, you can do small things with CMake script, but if you do bigger things, it'll waste your time. I tried to do it anyways because I thought maybe it didn't have to be that way. Maybe I really don't have to install Python or Ruby or Perl or whatever, maybe the build can be completely self-contained in CMake. But it looks like it would be substantial work to fix the lexical scoping or add Perl Compatible Regular Expression support. Maybe lexical scoping can't be fixed at all? And maybe PCRE is hitting a fly with a sledgehammer, way more regex power than most people are going to need. My concern is that if the status quo is maintained, CMake script will always be ugly to program with. This will put it at a disadvantage compared to build systems written in Python, Ruby, or Perl. I'm not just talking about SCons and so forth. I'm talking about a shop deciding, hey, screw this off-the-shelf stuff, we'll write our own custom build system in our favorite scripting language. It happens in the game industry all the time. Your thoughts? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Brandon Van Every wrote: My concern is that if the status quo is maintained, CMake script will always be ugly to program with. This will put it at a disadvantage compared to build systems written in Python, Ruby, or Perl. I'm not just talking about SCons and so forth. I'm talking about a shop deciding, hey, screw this off-the-shelf stuff, we'll write our own custom build system in our favorite scripting language. It happens in the game industry all the time. Your thoughts? CMake is a build system. In an ideal world, the language would be purely declarative. Basically, you would describe things you want to build, and CMake would build them. In practice, this is too restrictive, and a small amount of programming makes things easier. I never wanted CMake to replace perl, ruby, python or any other language. I wanted CMake to not depend on another language being installed. CMake only depends on a C++ compiler being around, so CMake can be built. Since CMake was developed for ITK (a c++ toolkit), I was adding no additional restrictions to the build process. The scripting stuff actually came out of a desire to automate the testing system without the use of tcl as was required in earlier version of Dart. I am sure the CMake language will be tweaked here and there, but if you have a big programming job that has nothing to do with building software, then CMake is the wrong choice. So, I think that if something is hard to build because of the CMake language, then we should fix it. People should use CMake because it is really easy to build complex things with, and not because it has a great language. The hard stuff should be done in C++ commands. For example, this small line of CMake code: add_library(foo SHARED foo.cxx) does some very complicated stuff as it builds shared libraries on many platforms, and different IDE's. And most of that is not done with the CMake language, it is done with the more powerful C++ language. BTW, I hope this does not become a long discussion, but I am sure it will... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] building an OSX app release
hello all, I've read a couple of recent posts that skirted around my issue, but didn't see any answers. I've been a programmer in the past, but I'm kind of new to the buildmiester role, so please forgive my ignorance. The situation I'm in is that I have installed and compiled several dependent packages on my build system using the recommended install procedures for each package (not cmake). I am using cmake to build my programs that currently link against these packages, and everything compiles nd runs fine. My current version of cmake uses FIND_PACKAGE to locate the dependencies. I now want to build a RELEASE version that will produce a standalone app bundle that will include the dependent libraries that I have been using in my builds. How can I tell cmake to take the libraries and include them in the build app? Does it matter if it is statically or dynamically linked? Is this as simple as copying the dylib over, or am I missing something? If you have attempted to do something like this, I would greatly appreciate your advice. -Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Tcl is a nice language for implementing declarative commands. It can be easily
built on about every platform out there, and the language rules are well known.
It is small, and very easy to compile a standalone Tcl based interpreter with
the CMake commands built in. The user would not need to have any language
installed, you could package the source with CMake or make it part of the cmake
binary you distribute. It is freely distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
Please see:
http://en.wikipedia.org/wiki/Tcl
for a description of this language. It would be very easy to implement a macro
as a procedure.
I would be happy to participate in any effort to port the cmake commands to a
Tcl interpreter. Please let me know if you are interested.
Regards,
Juan
-Original Message-
From: [EMAIL PROTECTED] on behalf of Bill Hoffman
Sent: Thu 11/1/2007 8:03 PM
To: Brandon Van Every
Cc: cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Brandon Van Every wrote:
My concern is that if the status quo is maintained, CMake script will
always be ugly to program with. This will put it at a disadvantage
compared to build systems written in Python, Ruby, or Perl. I'm not
just talking about SCons and so forth. I'm talking about a shop
deciding, hey, screw this off-the-shelf stuff, we'll write our own
custom build system in our favorite scripting language. It happens in
the game industry all the time.
Your thoughts?
CMake is a build system. In an ideal world, the language would be
purely declarative. Basically, you would describe things you want to
build, and CMake would build them. In practice, this is too
restrictive, and a small amount of programming makes things easier. I
never wanted CMake to replace perl, ruby, python or any other language.
I wanted CMake to not depend on another language being installed. CMake
only depends on a C++ compiler being around, so CMake can be built.
Since CMake was developed for ITK (a c++ toolkit), I was adding no
additional restrictions to the build process. The scripting stuff
actually came out of a desire to automate the testing system without the
use of tcl as was required in earlier version of Dart. I am sure the
CMake language will be tweaked here and there, but if you have a big
programming job that has nothing to do with building software, then
CMake is the wrong choice.
So, I think that if something is hard to build because of the CMake
language, then we should fix it. People should use CMake because it is
really easy to build complex things with, and not because it has a great
language. The hard stuff should be done in C++ commands.
For example, this small line of CMake code:
add_library(foo SHARED foo.cxx)
does some very complicated stuff as it builds shared libraries on many
platforms, and different IDE's. And most of that is not done with the
CMake language, it is done with the more powerful C++ language. BTW, I
hope this does not become a long discussion, but I am sure it will...
-Bill
___
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] building an OSX app release
On 2007-11-01 20:17-0500 Peter Crowley wrote: How can I tell cmake to take the libraries and include them in the build app? Does it matter if it is statically or dynamically linked? Is this as simple as copying the dylib over, or am I missing something? If you have attempted to do something like this, I would greatly appreciate your advice. Haven't done this myself, but I have thought about this possibility for PLplot. If we ever implement it (as an option), I would simply use the CMake INSTALL(FILES... command to install the external libraries to some appropriate location in our install tree with appropriate permissions. I believe this would work because the files to be installed can have absolute pathnames. CMake just sets up the install. The actual installation normally occurs as the result of the make install command. That's relevant to your problem because if you make a binary distribution with CPack, it will put all files normally installed with make install into a binary distribution file (compressed tarball or whatever you choose) instead, and I believe that such a binary distribution file is what you are really asking for. 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] improve the CMake language?
Sanchez, Juan wrote: Tcl is a nice language for implementing declarative commands. It can be easily built on about every platform out there, and the language rules are well known. It is small, and very easy to compile a standalone Tcl based interpreter with the CMake commands built in. The user would not need to have any language installed, you could package the source with CMake or make it part of the cmake binary you distribute. It is freely distributable and has a BSD license. We are not doing CMake in Tcl! We specifically avoided it at the start. From what I can tell it is declining, and the compile a standalone thing was never that easy, and we (Kitware) have plenty of experience with tcl. Please don't bother to refute this ... ( I am ranting a bit). CMake would require Tcl to build, right now it only needs C++, and I aim to keep it that way. I will say this. Unless someone is going to fork CMake, I do not think there will be a new language. I guess I should just stay on the side lines until the current change the language thread is over... SIGH... -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The user would not
need to have any language installed, you could package the source with
CMake or make it part of the cmake binary you distribute. It is freely
distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
I can't help myself, I have to respond :)
Or it could be:
add_library(foo SHARED foo.cxx)
Hey, wait, that already works... :)
The point is you don't need tcl, python, or ruby to add add a library.
You need a simple language, and I want it to work with only a c++
compiler and its standard libraries. So, when someone wants to build a
c++ program with CMake on a new platform, they don't first have to port
(tcl/python/ruby/XXX), the just need to have a c++ compiler, which they
should have if they are building a c++ application. It is sort of a
prerequisite to have a c++ compiler to build a c++ application, so we
know it will be there.
Sorry Juan, your suggestion is valid, and perhaps I should create a FAQ
entry like: Why the CMake Language? So, I can point to it when this
comes up.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Perl Compatible Regular Expressions. Why bother?
Ok, having been informed of the ultimate CMake language strategy... 2 months ago, a fellow and I talked about possibly putting PCRE into CMake. I looked at the PCRE library the other day. I was surprised at how vast it was. Tons of capabilities. A handful of customizable compilation defaults, which in permutation could confuse just about anyone as to basic expected behavior. At least there are options to declare I want exactly this kind of behavior in the regex itself, but boy, what a lot of blah blah blah. Why bother to improve CMake with this? I'm guessing I'm one of the only people who has gone off the regex deep end with CMake, and that almost no one else cares about these capabilities. I don't even know if I will care past my current project. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] building an OSX app release
On Nov 1, 2007, at 9:52 PM, Alan W. Irwin wrote: On 2007-11-01 20:17-0500 Peter Crowley wrote: How can I tell cmake to take the libraries and include them in the build app? Does it matter if it is statically or dynamically linked? Is this as simple as copying the dylib over, or am I missing something? If you have attempted to do something like this, I would greatly appreciate your advice. Haven't done this myself, but I have thought about this possibility for PLplot. If we ever implement it (as an option), I would simply use the CMake INSTALL(FILES... command to install the external libraries to some appropriate location in our install tree with appropriate permissions. I believe this would work because the files to be installed can have absolute pathnames. CMake just sets up the install. The actual installation normally occurs as the result of the make install command. That's relevant to your problem because if you make a binary distribution with CPack, it will put all files normally installed with make install into a binary distribution file (compressed tarball or whatever you choose) instead, and I believe that such a binary distribution file is what you are really asking for. Alan __ Alan W. Irwin There are some issues that Alan is skirting around. If you use dylibs for your support libraries AND you want a self contained App bundle that can be distributed there are a number of issues that you need to overcome. 0. Are you going to produce a Universal Binary or single arch applciation 1. The install_name of the dylibs need to be changed to something like @executable_path/../PlugIns/[Library Name] 2. You need to copy these libraries into the App package 3. You will need to change the install_name paths of each library that the executable links against to point to the path in #1. 4. You will need to package your final application in a tar ball, zip file or Disk Image. There are lots of ways to get to these accomplished. You can use cmake for some of it. You can write a shell script that does all. You can use a combination of the two. I have an application that relies on HDF5, Expat, Tiff and Qt4. I have cmake configure a shell script and then run the shell script. The shell script copies all the files from their installed locations around my system, reconfigures the install_name of each library and reconfigures the executable to properly find those libraries in the App bundle. If you have control over the compilation of all your support libraries (minus those found on the OS X System itself) then I would probably build as static libraries then link against those static libraries. Takes all the dylib confusion out of the equation. You can see my scripts and projects at the following location: http://titanium.imts.us/viewvc/Task_7/MXATools/ which references this project: http://titanium.imts.us/viewvc/Task_7/MXADataModel/ The scripts are located in the Resources folder of each project. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] improve the CMake language?
Hello Bill,
add_library(foo SHARED foo.cxx)
won't work.
Parenthesis are not part of the standard syntax, and worth getting Tcl to
understand them.
Tcl is a simple language, and is well understood. It has already been ported
to about every platform out there. You don't need QT or wxWidgets, because the
Tk extensions of it already work.
Many features in the CMake language don't really work the way people expect, or
are not documented, or both.
If anyone would like to fork cmake with me, I'm game.
Features:
Tcl frontend featuring modern dynamic language constructs and consistent syntax.
C pre-processor based dependency scanner
Accurate and up to date documentation
Focus on getting build system that works, because all of the language
constructs have already been written.
Developers who are not hostile to ideas concerning improvements to the language.
Regards,
Juan
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Thu 11/1/2007 9:18 PM
To: Sanchez, Juan
Cc: Bill Hoffman; Brandon Van Every; cmake@cmake.org
Subject: Re: [CMake] improve the CMake language?
Sanchez, Juan wrote:
Tcl is a nice language for implementing declarative commands. It can be
easily built on about every platform out there, and the language rules
are well known. It is small, and very easy to compile a standalone Tcl
based interpreter with the CMake commands built in. The user would not
need to have any language installed, you could package the source with
CMake or make it part of the cmake binary you distribute. It is freely
distributable and has a BSD license.
add_library(foo SHARED foo.cxx)
could become
add_library {foo SHARED foo.cxx}
or even
add_library -name foo -type SHARED foo.cxx
I can't help myself, I have to respond :)
Or it could be:
add_library(foo SHARED foo.cxx)
Hey, wait, that already works... :)
The point is you don't need tcl, python, or ruby to add add a library.
You need a simple language, and I want it to work with only a c++
compiler and its standard libraries. So, when someone wants to build a
c++ program with CMake on a new platform, they don't first have to port
(tcl/python/ruby/XXX), the just need to have a c++ compiler, which they
should have if they are building a c++ application. It is sort of a
prerequisite to have a c++ compiler to build a c++ application, so we
know it will be there.
Sorry Juan, your suggestion is valid, and perhaps I should create a FAQ
entry like: Why the CMake Language? So, I can point to it when this
comes up.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
