Re: [CMake] Small, realistic Cpack example
On Tuesday 16 September 2008, Mike Jackson wrote: After some tinkering this afternoon with a small cmake project on OS X (based on Qt4) I was able to use the latest bits from CMake CVS to create a stand alone OS X bundle that correctly runs install_name_tool on the .app bundle and copies needed libraries into the bundle. I have a small example project that uses just Qt4 is anyone is interested... Oh, yes! Requirements: CMake CVS. OS X. Qt4 Caveats: The new functionality places libraries in the same directory (MacOS) as the executable which (again philosophically only) kinda goes against what Apple would suggest BUT DOES WORK. David Cole who wrote the code was kind enough to add a hook into the code so that you can place dylibs in another directory if you want. I have a more complex example where I exploit that hook to place the Qt4 libraries and a few other 3rd party libs into MyApp.app/Contents/ Libraries/*.dylib Again, if anyone wants to look at the latest bleeding edge feel free to email me. I am still discussing this solution/tweaks with the CMake devs... Yes, I'm very interested, both in the simple and in the complex example. I've got CMake from cvs (in the first place to crib from, but I've got it installed, too). -- Boudewijn Rempt | http://www.valdyas.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
On Tuesday 16 September 2008, you wrote: Hate to say it, but I've gone through this with several projects now, and there seems to be an irreducible lower-limit on complexity. Yes... That seems to be true. Wherever I look, people are always doing this kind of thing slightly differently. You can use that first link to browse through our entire distribution hierarchy, which organizes packaging for all three platforms: When I've figured out how to do what we need to I'll try to make a nice, detailed write-up :-) -- Boudewijn Rempt | http://www.valdyas.org ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
Timenkov Yuri wrote:
On Tue, Sep 16, 2008 at 11:08 AM, Jesper Eskilson [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi all,
I get several weird printouts in our build-server logs which I don't get
when I'm building from an (interactive) terminal:
Dependee
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/DependInfo.cmake
is newer than depender
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/depend.internal.
I've tried searching for Dependee in both the generated makefiles and
in the CMake source code, but without success.
This output comes from make utility. These problems may occur if you
have problems with time on your server. Check that your VCS server,
developers (who commit to VCS) and build server have same time.
I'm sorry, but this is not correct. CMake prints out the message in
cmDepends.cxx. (Maybe you were thinking about the clock-skew detected
message which is printed when make discovers that newly created files
gets timestamps in the future?)
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
On Wed, Sep 17, 2008 at 10:59 AM, Jesper Eskilson [EMAIL PROTECTED]wrote:
Timenkov Yuri wrote:
On Tue, Sep 16, 2008 at 11:08 AM, Jesper Eskilson [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Hi all,
I get several weird printouts in our build-server logs which I don't
get
when I'm building from an (interactive) terminal:
Dependee
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/DependInfo.cmake
is newer than depender
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/depend.internal.
I've tried searching for Dependee in both the generated makefiles and
in the CMake source code, but without success.
This output comes from make utility. These problems may occur if you have
problems with time on your server. Check that your VCS server, developers
(who commit to VCS) and build server have same time.
I'm sorry, but this is not correct.
Yes, I understood it from your previous message.
CMake prints out the message in cmDepends.cxx. (Maybe you were thinking
about the clock-skew detected message which is printed when make discovers
that newly created files gets timestamps in the future?)
But it prints this also from cmLocalUnixMakefileGenerator3.cxx, which I
suppose is your case. And yes, I first thought about clock skew detected.
Anyway, the printout is inside a if(this-Verbose) { ... }, so presumable
it is something which can be switched on/off.
And it seems not a problem, because CMake just tells why it regenerates
dependencies.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
Timenkov Yuri wrote:
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
And it seems not a problem, because CMake just tells why it regenerates
dependencies.
But it clutters my make output. I like my make output to be as clean as
possible. Actually I would like to get rid of the Building CXX
object... messages as well -- when running make with the -s option
there should be no output at all except error messages. But that is
another issue.
Anyway, the culprit is that I ran make like this
$ make -j2 all VERBOSE=
i.e. the VERBOSE variable is set, but to the empty string.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Lint Integration
Hi,
I´d like to integrate PC-Lint (www.gimpel.com, a source code checker for
C/C++) to my cmake build system
(Cross-Compile for an embedded Power PC with WindRiver Compiler, which is
running on Windows).
My first idea was to add a command to CMAKE_C_COMPILE_OBJECT, but I don't
know how to extract the include and definition command line options from
FLAGS or DEFINES.:
SET(CMAKE_C_COMPILE_OBJECT
CMAKE_C_COMPILER DEFINES FLAGS -Wa,-l -o OBJECT -c
SOURCE
${PCLINT_EXECUTABLE} +v -iC:\Lint std.lint ??Include and
Definition Flags?? SOURCE )
How could i do this (is there a possibility to make string manipulation?),
or is there an other way to integrate lint?
PC-Lint should check each c-File, which is compiled by the Compiler.
Thanks a lot
Engineering Center Steyr GmbH Co KG
Geschaeftsfuehrende Gesellschaft: Engineering Center Steyr GmbH
Geschaeftsfuehrer der geschaeftsfuehrenden Gesellschaft: Dipl. Ing. Franz
Dorfer
Sitz der geschaeftsfuehrenden Gesellschaft: 4300 St. Valentin, Oesterreich
Firmenbuchgericht: St. Poelten / FN 140816h
Sitz der Gesellschaft: 4300 St. Valentin, Steyrer Strasse 32, Oesterreich
Firmenbuchgericht: St. Poelten / FN 222001y
CONFIDENTIALITY NOTE: This message contains information which may be
privileged or confidential, or exempt from disclosure under applicable
law. If the reader of this message is not the intended recipient, or the
employee or agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify us
immediately by return e-mail to the sender of this message.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o : Permission denied
I am getting this weird behavior on my linux debian stable: ... CMake Error: TestBigEndian Failed to run with output: /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build make[1]: Entering directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o /usr/bin/gcc-4.3 -Wall -W -o CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -c /usr/share/cmake-2.4/Modules/TestBigEndian.c Linking C executable cmTryCompileExec /usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake /usr/bin/gcc-4.3 -Wall -W -fPIC CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -o cmTryCompileExec -rdynamic make[1]: Leaving directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' Permission denied -- Check if the system is big endian -- Check if the system is big endian - big endian ... I have plenty of disk space, but it looks like CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o does not get cleanup properly and thus the second time the compilation happen gcc is not given the right to write the output file. Anyone seen that before ? cmake 2.4.5 (default debian package) Thanks, -- Mathieu Ps: my system is little endian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o : Permission denied
Weird... this does not happen anymore with cmake 2.6 It would be nice if I had a solution for the default cmake installation tough. Thanks! On Wed, Sep 17, 2008 at 11:27 AM, Mathieu Malaterre [EMAIL PROTECTED] wrote: I am getting this weird behavior on my linux debian stable: ... CMake Error: TestBigEndian Failed to run with output: /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build make[1]: Entering directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o /usr/bin/gcc-4.3 -Wall -W -o CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -c /usr/share/cmake-2.4/Modules/TestBigEndian.c Linking C executable cmTryCompileExec /usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake /usr/bin/gcc-4.3 -Wall -W -fPIC CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -o cmTryCompileExec -rdynamic make[1]: Leaving directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' Permission denied -- Check if the system is big endian -- Check if the system is big endian - big endian ... I have plenty of disk space, but it looks like CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o does not get cleanup properly and thus the second time the compilation happen gcc is not given the right to write the output file. Anyone seen that before ? cmake 2.4.5 (default debian package) Thanks, -- Mathieu Ps: my system is little endian -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] find_package vs. include
Hi all, As far as I can tell both (for example) find_package(MPI) and include(FindMPI) do the same thing. All the required bits and pieces are set and usable for the rest of the build. Is there any difference under the hood, and should I be using one in preference to the other? Thanks, Rob ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o : Permission denied
Not sure this will ever happen to anyone again, but this partition was mounted with special option: /dev/mapper/lvm-storage /backupext3 noatime,nodev,nosuid,noexec 0 2 not a cmake bug thus. On Wed, Sep 17, 2008 at 11:35 AM, Mathieu Malaterre [EMAIL PROTECTED] wrote: Weird... this does not happen anymore with cmake 2.6 It would be nice if I had a solution for the default cmake installation tough. Thanks! On Wed, Sep 17, 2008 at 11:27 AM, Mathieu Malaterre [EMAIL PROTECTED] wrote: I am getting this weird behavior on my linux debian stable: ... CMake Error: TestBigEndian Failed to run with output: /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build make[1]: Entering directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o /usr/bin/gcc-4.3 -Wall -W -o CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -c /usr/share/cmake-2.4/Modules/TestBigEndian.c Linking C executable cmTryCompileExec /usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake /usr/bin/gcc-4.3 -Wall -W -fPIC CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o -o cmTryCompileExec -rdynamic make[1]: Leaving directory `/backup/mathieu/GDCM2/gdcm-gcc43/CMakeFiles/CMakeTmp' Permission denied -- Check if the system is big endian -- Check if the system is big endian - big endian ... I have plenty of disk space, but it looks like CMakeFiles/cmTryCompileExec.dir/usr/share/cmake-2.4/Modules/TestBigEndian.o does not get cleanup properly and thus the second time the compilation happen gcc is not given the right to write the output file. Anyone seen that before ? cmake 2.4.5 (default debian package) Thanks, -- Mathieu Ps: my system is little endian -- Mathieu -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Customizing target locations with VS generator
Hello
I set the CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY
and CMAKE_RUNTIME_OUTPUT_DIRECTORY to, say, ${CMAKE_SOURCE_DIR}/bin .
I also set suffixes so any target in any build configuration has a
unique name within my build tree.
CMake's behavior with Visual Studio generators is to generate
(read-only) properties on my targets, like:
LOCATION = c:/path/to/my/project/bin/$(OutDir)/mytarget.dll
DEBUG_LOCATION = c:/path/to/my/project/bin/DEBUG/mytarget_d.dll
RELEASE_LOCATION = c:/path/to/my/project/bin/RELEASE/mytarget_r.dll
This is great but I would really love to find a way to remove that
$(OutDir) from the way, so that all my targets are put into the same
directory, not depending on the build config. There is no possible
filename clash since all my targets have different suffixes.
Is there a simple solution to my problem?
Thank you for your time,
Kind regards,
Cyril
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.5 with windows mobile
Hi, I am about to do that right now. I just discovered that there is a tool called dumpbim with the flag /DIRECTIVES and it provides output like: Linker Directives - /manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /DEFAULTLIB:msvcprtd /manifestdependency:type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /DEFAULTLIB:MSVCRTD /DEFAULTLIB:OLDNAMES Is there something like grep in cmake? Because then I could improve the amd64 check inside Windows-cl.cmake to detect the other architectures too. What happened to the two windows SDK patches, that made the visual studio generator create files with selectable SDKs? Are there in the queue of patches to apply to cmake, or still not ready yet? kind regards Andreas Pokorny 2008/8/5 Alexander Neundorf [EMAIL PROTECTED]: On Friday 01 August 2008, Andreas Pokorny wrote: Hello, We are building for Win32, WinCE, QNX, Linux and hopefully soon also Symbian, with mostly cross compile setups using cmake. But note, that right now cross compiling only works for gnu make and nmake. You wanted to clean up the WinCE stuff before end in August. Is this still on your plan ? It would be nice to get this in, there are quite a few requests for this. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.5 with windows mobile
Hello,
Small correction, the magic switch ist /HEADERS, and I came up with
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} /c /nologo test.c )
EXECUTE_PROCESS(COMMAND dumpbin /HEADERS test.obj OUTPUT_VARIABLE
TEST_HEADERINFO )
STRING(REGEX MATCH machine \\(([^\\)]*)\\) RESULT ${TEST_HEADERINFO})
SET(CMAKE_CL_MACHINE_TYPE ${CMAKE_MATCH_1})
MESSAGE(STATUS ${CMAKE_CL_MACHINE_TYPE})
Is there a better way?
Andreas
2008/9/17 Andreas Pokorny [EMAIL PROTECTED]:
Hi,
I am about to do that right now. I just discovered that there is a
tool called dumpbim with the flag /DIRECTIVES
and it provides output like:
Linker Directives
-
/manifestdependency:type='win32'
name='Microsoft.VC80.DebugCRT'
version='8.0.50727.762'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b'
/DEFAULTLIB:msvcprtd
/manifestdependency:type='win32'
name='Microsoft.VC80.DebugCRT'
version='8.0.50727.762'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b'
/DEFAULTLIB:MSVCRTD
/DEFAULTLIB:OLDNAMES
Is there something like grep in cmake? Because then I could improve
the amd64 check inside Windows-cl.cmake
to detect the other architectures too.
What happened to the two windows SDK patches, that made the visual
studio generator create files with selectable
SDKs? Are there in the queue of patches to apply to cmake, or still
not ready yet?
kind regards
Andreas Pokorny
2008/8/5 Alexander Neundorf [EMAIL PROTECTED]:
On Friday 01 August 2008, Andreas Pokorny wrote:
Hello,
We are building for Win32, WinCE, QNX, Linux and hopefully soon also
Symbian, with mostly
cross compile setups using cmake. But note, that right now cross
compiling only works for gnu make and nmake.
You wanted to clean up the WinCE stuff before end in August. Is this still on
your plan ? It would be nice to get this in, there are quite a few requests
for this.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cannot invoke project() from a separate cmake file
Hello I am confronted to the following problem: It seems that the PROJECT command cannot be invoked in a macro that is located in a cmake file that is included by my main CMakeLists.txt file. This issue has been encountered a few years ago: http://www.cmake.org/pipermail/cmake/2005-February/006082.html . This is a minor deal, but I could use a fix! Thanks for your time, Kind regards, Cyril ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package vs. include
2008/9/17 Robert Haines [EMAIL PROTECTED]: Hi all, As far as I can tell both (for example) find_package(MPI) and include(FindMPI) do the same thing. All the required bits and pieces are set and usable for the rest of the build. Is there any difference under the hood, and should I be using one in preference to the other? 'find_package' has many more option than 'include' find_package(package [major[.minor[.patch]]] [EXACT] [QUIET] [[REQUIRED|COMPONENTS] [components...]] [NO_MODULE] [NAMES name1 [name2 ...]] [CONFIGS config1 [config2 ...]] [HINTS path1 [path2 ... ]] [PATHS path1 [path2 ... ]] [PATH_SUFFIXES suffix1 [suffix2 ...]] [NO_DEFAULT_PATH] [NO_CMAKE_ENVIRONMENT_PATH] [NO_CMAKE_PATH] [NO_SYSTEM_ENVIRONMENT_PATH] [NO_CMAKE_BUILDS_PATH] [NO_CMAKE_SYSTEM_PATH] [CMAKE_FIND_ROOT_PATH_BOTH | ONLY_CMAKE_FIND_ROOT_PATH | NO_CMAKE_FIND_ROOT_PATH]) include(file1 [OPTIONAL] [RESULT_VARIABLE VAR]) include(module [OPTIONAL] [RESULT_VARIABLE VAR]) You should read the doc for find_package. My opinion is that you should use find_package(XXX) for a FindXXX.cmake module. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package vs. include
You should read the doc for find_package. My opinion is that you should use find_package(XXX) for a FindXXX.cmake module. Thanks, I have just installed a 2.6 version of CMake and the documentation is much, much better. I have the CMake book but version 2.2 and it is now woefully out of date. Cheers, Rob ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] PackageConfig.cmake = FIND_PACKAGE
Hallo,
I have two CMAKE-Module files (FindMAX.cmake intlConfig.cmake) Both
are located in a separate directory (please, see the script below)
FIND_PACKAGE can find MAX with no problems, but it comes in trouble
looking for intl.
It changes the name correctly to intlConfig.cmake, but it cannot
localize the file.
Resulting error:
CMake Error: intl_DIR is not set. It must be set to the directory
containing intlConfig.cmake in order to use intl.
Obviously, FIND_PACKAGE cannot find the module-file with the NAMES
option.
So, where is my error?
Greetings
Micha
PROJECT(TD)
SET(CMAKE_MODULE_PATH /usr/local/share/CMake)
FIND_PACKAGE(MAX REQUIRED)
INCLUDE_DIRECTORIES(${MAX_INCLUDE_DIR})
FIND_PACKAGE(intl REQUIRED NAMES intl)
INCLUDE_DIRECTORIES(${INTL_INCLUDE_DIR})
SET(_src sayhallo.c)
ADD_EXECUTABLE(ULS ${_src})
TARGET_LINK_LIBRARIES(ULS ${INTL_LIBRARY} ${MAX_LIBRARY})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
Boudewijn Rempt wrote: On Tuesday 16 September 2008, Mike Jackson wrote: After some tinkering this afternoon with a small cmake project on OS X (based on Qt4) I was able to use the latest bits from CMake CVS to create a stand alone OS X bundle that correctly runs install_name_tool on the .app bundle and copies needed libraries into the bundle. I have a small example project that uses just Qt4 is anyone is interested... Oh, yes! I too would be interested in seeing this, Mike. Any chance you can put it up somewhere public ? -- Regards Steve Collyer Netspinner Ltd ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make -j and cmake
In case my first post to the list went missing, re-posting. (If my post did reach the list, help! :) Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Chaney Sent: 12 September 2008 10:54 To: cmake@cmake.org Subject: [CMake] make -j and cmake I have been attempting to switch CMAKE from building using nmake (via a customised Microsoft Visual Studio 8 generator) to a cygwin make (using Unix Makefiles generator) in order to use the -j option. A previous post (http://www.cmake.org/pipermail/cmake/2008-April/021338.html) noted that Bill Hoffman had made a special version of make that fixed/reverted some path/drive letter change in the main CVS branch. Although the version of make available on the cmake website seems to work OK from the command line, when I then run it under Incredibuild (to move from parallel to distributed builds) I get a crash inside make.exe. I have spoken to Xoreax (the makers of Incredibuild) and they are interested but unable to assist, as the problem is inside make and not their product. The logical step then was to make my own debug version of make from the source, but I cannot get the same behaviour from a locally compiled make (using latest CVS as downloaded from Savannah) as I do with the version from the cmake website. So to the questions: 1) What modifications were made to the CVS of make? Is there a certain date I should sync to? (I notice that it says the -j option only takes effect for that call to make, and subsequent calls have to have -j added to them; I dont think the cmake generated makefile will do this for me, will it?) 2) When I get 'valid' source, what parameters were used in the config.h? Most importantly, was HAVE_CYGWIN_MAKE or HAVE_MKS_MAKE defined? Apologies of this seems tangential, but unless I am misunderstanding the CVS repository make hasn't been released for 2+ years so the change from Bill has never been released... ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
http://www.bluequartz.net/QTTest.tar.gz It was just over the size limit. I guess I could have removed the icon file.. --- Mike Jackson - Principal Software Engineer www.bluequartz.net On Sep 17, 2008, at 9:44 AM, Stephen Collyer wrote: Boudewijn Rempt wrote: On Tuesday 16 September 2008, Mike Jackson wrote: After some tinkering this afternoon with a small cmake project on OS X (based on Qt4) I was able to use the latest bits from CMake CVS to create a stand alone OS X bundle that correctly runs install_name_tool on the .app bundle and copies needed libraries into the bundle. I have a small example project that uses just Qt4 is anyone is interested... Oh, yes! I too would be interested in seeing this, Mike. Any chance you can put it up somewhere public ? -- Regards Steve Collyer Netspinner Ltd ___ 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] Query about FindXXX files
In CMake 2.6.1, the header for FindTIFF.cmake says: # This module defines # TIFF_INCLUDE_DIR, where to find tiff.h, etc. # TIFF_LIBRARIES, libraries to link against to use TIFF. # TIFF_FOUND, If false, do not try to use TIFF. # also defined, but not for general use are # TIFF_LIBRARY, where to find the TIFF library. However, after executing: FIND_PACKAGE(TIFF) my CMakeCache.txt now has the following entries: TIFF_INCLUDE_DIR:PATH=/usr/include TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so So, in other words, the not for general use TIFF_LIBRARY variable is placed in my cache, while the promised TIFF_LIBRARIES variable is not. Something similar seems to be happening for FindJPEG, FindMPEG, FindPNG, etc. So I am probably just missing something here. Can somebody perhaps explain to me what the reasoning behind the LIBRARY/LIBRARIES approach is? Many thanks in advance, -- Leo Breebaart [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Query about FindXXX files
Leo Breebaart schrieb: In CMake 2.6.1, the header for FindTIFF.cmake says: # This module defines # TIFF_INCLUDE_DIR, where to find tiff.h, etc. # TIFF_LIBRARIES, libraries to link against to use TIFF. # TIFF_FOUND, If false, do not try to use TIFF. # also defined, but not for general use are # TIFF_LIBRARY, where to find the TIFF library. However, after executing: FIND_PACKAGE(TIFF) my CMakeCache.txt now has the following entries: TIFF_INCLUDE_DIR:PATH=/usr/include TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so So, in other words, the not for general use TIFF_LIBRARY variable is placed in my cache, while the promised TIFF_LIBRARIES variable is not. Is there a reason why you want to have the other vars in CMakeCache.txt? Isn't it enough to have them available? Christian ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindFreetype wrong?
Hi,
I want to use FIND_PACKAGE( FREETYPE ) on windows. But it looks like it
does not work.
If i change in FindFreetype.cmake:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
$ENV{FREETYPE_DIR}
NO_DEFAULT_PATH
PATH_SUFFIXES include
)
to this:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
$ENV{FREETYPE_DIR}/include
NO_DEFAULT_PATH
)
It starts working. I tried setting FREETYPE_DIR environment variable
with and without a / at the end, but that is not solving it.
Even setting this:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
c:/soft/freetype/GnuWin32
NO_DEFAULT_PATH
PATH_SUFFIXES include
)
does not work, so i think it is something within Cmake itself. Maybe
something with window paths??
This is with Visual studio 8 + Cmake 2.6 patch 0
Klaas
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Query about FindXXX files
Christian Ehrlicher [EMAIL PROTECTED] writes:
Leo Breebaart schrieb:
In CMake 2.6.1, the header for FindTIFF.cmake says:
# This module defines
# TIFF_INCLUDE_DIR, where to find tiff.h, etc.
# TIFF_LIBRARIES, libraries to link against to use TIFF.
# TIFF_FOUND, If false, do not try to use TIFF.
# also defined, but not for general use are
# TIFF_LIBRARY, where to find the TIFF library.
However, after executing:
FIND_PACKAGE(TIFF)
my CMakeCache.txt now has the following entries:
TIFF_INCLUDE_DIR:PATH=/usr/include
TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so
So, in other words, the not for general use TIFF_LIBRARY
variable is placed in my cache, while the promised TIFF_LIBRARIES
variable is not.
Is there a reason why you want to have the other vars in
CMakeCache.txt? Isn't it enough to have them available?
Yes, it should be, I suppose.
My use case is that I have in my sources a 3rd party non-CMake
library that I need to include in my overall build. So I have
'cmakified' that library, and since it relies on libtiff, I call
the FIND_PACKAGE(TIFF) in that CMakeFile, so it can also compile
standalone.
Now elsewhere in my sources I have an application that actually
uses the 3rd party library, but which of course still needs to
link to libtiff as well. So I was attempting to add
${TIFF_LIBRARIES} to that application's TARGET_LINK_LIBRARIES,
when I discovered the issues in my earlier message.
So if the Cache is not the right way to pass information
'sideways' in your build tree, what is? I think I understand (but
please correct if I get it wrong -- I am new to CMake) that if I
call FIND_PACKAGE(TIFF) at a high enough level, i.e. at my top
level CMakeLists.txt, the TIFF_LIBRARIES var will be available to
all 'lower' level directories reached via ADD_SUBDIRECTORY.
But in this case, it still seems somehow wrong to me not to keep
the check where it belongs, i.e. with the application. But the
library is not a subdir from the application dir (and shouldn't
be -- it may be used elsewhere as well), so I still have that
'passing information sideways' problem. TIFF_INCLUDE_DIR is no
problem, because FIND_PACKAGE(TIFF) *does* put that one in the
cache...
--
Leo Breebaart [EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, realistic Cpack example
On Tuesday 16 September 2008 20:13:15 Mike Arthur wrote: I've written a CMake Module to do this that I've been meaning to add to the CMake bugtracker for ages. I showed it to Alex Neundorf at Akademy and he seemed very interested. Anyone else? Mike Jackson, I feel there are too many people called Mike in this thread. Fancy changing your name? ;) Anyway, the OSX relocation module I posted is here: http://public.kitware.com/Bug/view.php?id=7695 I'm going to post a separate message about this in case anyone else is interested and ignoring this thread. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to provide QT_LIBRARIES_RELEASE and QT_LIBRARIES_DEBUG
I've written a module (based on some work from the archives here) that provides QT_LIBRARIES_RELEASE and QT_LIBRARIES_DEBUG variables for easier installation of dynamic Qt applications. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7691 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to get Qt .dll library location on Windows
I've written a simple module that gets the .dll file of a Qt library on Windows given the .lib file. I've found this pretty useful when installing libraries to be bundled with a dynamic Qt executable If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7692 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to get UNIX symlinks from a library's name
I've written a module get the associated symlinks for a library when given the library name or another */lib/* symlink on UNIX systems. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7693 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to install files to the MSVC build directories
Visual Studio users expect to be able to click Run and have the application run correctly from the build directory. I've written a module that provides this functionality. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7694 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Module to relocate an OSX library
I've written a macro to relocate an OSX library. If anyone is interested in this then please either comment on the bug below or email me. http://public.kitware.com/Bug/view.php?id=7695 Thanks to my employer, Mendeley (http://www.mendeley.com) for allowing me to freely share these. -- Cheers, Mike Arthur http://mikearthur.co.uk/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Query about FindXXX files
Leo Breebaart schrieb:
Christian Ehrlicher [EMAIL PROTECTED] writes:
Leo Breebaart schrieb:
In CMake 2.6.1, the header for FindTIFF.cmake says:
# This module defines
# TIFF_INCLUDE_DIR, where to find tiff.h, etc.
# TIFF_LIBRARIES, libraries to link against to use TIFF.
# TIFF_FOUND, If false, do not try to use TIFF.
# also defined, but not for general use are
# TIFF_LIBRARY, where to find the TIFF library.
However, after executing:
FIND_PACKAGE(TIFF)
my CMakeCache.txt now has the following entries:
TIFF_INCLUDE_DIR:PATH=/usr/include
TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so
So, in other words, the not for general use TIFF_LIBRARY
variable is placed in my cache, while the promised TIFF_LIBRARIES
variable is not.
Is there a reason why you want to have the other vars in
CMakeCache.txt? Isn't it enough to have them available?
Yes, it should be, I suppose.
My use case is that I have in my sources a 3rd party non-CMake
library that I need to include in my overall build. So I have
'cmakified' that library, and since it relies on libtiff, I call
the FIND_PACKAGE(TIFF) in that CMakeFile, so it can also compile
standalone.
Now elsewhere in my sources I have an application that actually
uses the 3rd party library, but which of course still needs to
link to libtiff as well. So I was attempting to add
${TIFF_LIBRARIES} to that application's TARGET_LINK_LIBRARIES,
when I discovered the issues in my earlier message.
Once you called FIND_PACKAGE(TIFF) all TIFF_foo vars are set to the
correct value - at least it should be (and I never had problems with this)
Christian
signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross compiling toolchain: Substitution in OBJECTS variable
Dear CMake users list,
I am currently development a CMake cross build platform
definition to support Microchips C18 C compiler[1].
I encountered the problem that C18's linker does not like '/' as
path delimiter which is why I need some substitution for the
filenames contained in the magic OBJECTS variable (to '\').
The only solution I found is to create a temporary batch file and
to use cmd's text replacement facilities.
Here is the platform file in question:
CMake version: 2.6.1
CMake generator: Unix Makefiles
Build platform: win32 (Vista)
# Suffixes of static libraries and object files created by us
SET(CMAKE_STATIC_LIBRARY_SUFFIX .lib)
SET(CMAKE_C_OUTPUT_EXTENSION .o)
SET(CMAKE_C_LINK_EXECUTABLE mplink.exe)
SET(CMAKE_AR mplib.exe)
# Linking against static variables: /l path/to/lib libTheLibrary.lib
SET(CMAKE_LIBRARY_PATH_FLAG /l)
SET(CMAKE_LINK_LIBRARY_FLAG lib)
SET(CMAKE_LINK_LIBRARY_SUFFIX .lib)
# Compile a C file into an object file
SET(CMAKE_C_COMPILE_OBJECT CMAKE_C_COMPILER FLAGS -O
-fo=\\\OBJECT\\\ SOURCE)
# Link object files to an executable
SET(CMAKE_C_LINK_EXECUTABLE CMAKE_LINKER OBJECTS CMAKE_C_LINK_FLAGS
LINK_FLAGS LINK_LIBRARIES /o TARGET /w)
# Create static library
# Problem 1: APPEND does not work (not invoked?)
# -- do all work in CREATE
# Problem 2: Need to use \ as path delimiter in OBJECTS.
# Is text replacement possible?
#SET (CMAKE_C_ARCHIVE_CREATE CMAKE_AR /c TARGET; CMAKE_AR /r TARGET
OBJECTS)
#SET (CMAKE_C_ARCHIVE_APPEND echo append)
# Create static library
#
# Caution: Object paths to be passed to mplib must use
# '\' as path delimiter!
# TODO: Using temporary batch file to perform text replacement / -- \
SET(CMAKE_C_CREATE_STATIC_LIBRARY
\${CMAKE_COMMAND}\ -E remove TARGET
\${CMAKE_COMMAND}\ -E remove c18_build_archive.bat
CMAKE_AR /c TARGET
echo set objs=OBJECTS c18_build_archive.bat
echo CMAKE_AR /r TARGET %%objs:/=\\%% c18_build_archive.bat
c18_build_archive.bat
\${CMAKE_COMMAND}\ -E remove c18_build_archive.bat
)
===
As you can see, there is also a minor problem with
CMAKE_C_ARCHIVE_APPEND not being invoked. I tried to work around the
latter issue by using cmd's ; operator in CMAKE_C_ARCHIVE_CREATE.
Could you please give my some piece of advice, especially for the text
substitution problem? As soon as I have a clean solution, I would
certainly like to submit the platform definition file to the CMake
distribution.
Here is how I invoke CMake:
cmake -G Unix Makefiles
-D CMAKE_TOOLCHAIN_FILE:FILEPATH=Toolchain-C18.cmake src dir
=== Toolchain-C18.cmake ===
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER(mcc18.exe MicrochipC18)
=
Please let me know, if you need further details.
Thanks,
Simon
[1]
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGEnodeId=1406dDocName=en010014
--
Lehrstuhl für Dipl.-Inf. Simon Barner
Robotik und eingebettete Systeme Technische Universitaet Muenchen
Fakultaet fuer Informatik
Lehrstuhl I/6 Boltzmannstrasse 3 85748 Garching http://www6.in.tum.de
Tel.: ++49 (0)89 289-18111 Fax: 18107 Email: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] find windows libraries from within cygwin
I noticed that while running the cygwin version of CMake 2.6.0 the following variables are set: CMAKE_FIND_LIBRARY_SUFFIXES = .dll;.dll.a;.a CMAKE_FIND_LIBRARY_PREFIXES = cyg;lib Is there a reason why they couldn't be set to this: # Adds .lib to the list CMAKE_FIND_LIBRARY_SUFFIXES = .dll;.dll.a;.a;.lib # Adds to the list CMAKE_FIND_LIBRARY_PREFIXES = cyg;lib; I believe that .lib files can be linked against using cygwin gcc. Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
On 2008-09-17 09:10+0200 Jesper Eskilson wrote:
Timenkov Yuri wrote:
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
And it seems not a problem, because CMake just tells why it regenerates
dependencies.
But it clutters my make output. I like my make output to be as clean as
possible. Actually I would like to get rid of the Building CXX object...
messages as well -- when running make with the -s option there should be no
output at all except error messages. But that is another issue.
Anyway, the culprit is that I ran make like this
$ make -j2 all VERBOSE=
i.e. the VERBOSE variable is set, but to the empty string.
I doubt setting VERBOSE at the end like that after the all target will
work. For that order make probably assumes VERBOSE= is a target which is
not what you want.
I do know that the forms
make VERBOSE=1 -j2 all
or
make VERBOSE=0 -j2 all
do work.
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] make -j and cmake
Hello Jim Chaney, What version of CMake are you using? I'm using 2.6.2-RC4 here. I often use make -j7 on my company's 8 core Mac Pro. (Leaving the remaining core to manage interprocess communications, run make, manage disk caches, etc.) Using that configuration I can build ParaView in only 7-10 minutes. Occasionally it bombs out but if I repeat the make it picks up where it left off and finishes the build. --- On Wed, 9/17/08, Jim Chaney [EMAIL PROTECTED] wrote: From: Jim Chaney [EMAIL PROTECTED] Subject: Re: [CMake] make -j and cmake To: cmake@cmake.org Date: Wednesday, September 17, 2008, 1:47 PM In case my first post to the list went missing, re-posting. (If my post did reach the list, help! :) Jim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Chaney Sent: 12 September 2008 10:54 To: cmake@cmake.org Subject: [CMake] make -j and cmake I have been attempting to switch CMAKE from building using nmake (via a customised Microsoft Visual Studio 8 generator) to a cygwin make (using Unix Makefiles generator) in order to use the -j option. A previous post (http://www.cmake.org/pipermail/cmake/2008-April/021338.html) noted that Bill Hoffman had made a special version of make that fixed/reverted some path/drive letter change in the main CVS branch. Although the version of make available on the cmake website seems to work OK from the command line, when I then run it under Incredibuild (to move from parallel to distributed builds) I get a crash inside make.exe. I have spoken to Xoreax (the makers of Incredibuild) and they are interested but unable to assist, as the problem is inside make and not their product. The logical step then was to make my own debug version of make from the source, but I cannot get the same behaviour from a locally compiled make (using latest CVS as downloaded from Savannah) as I do with the version from the cmake website. So to the questions: 1) What modifications were made to the CVS of make? Is there a certain date I should sync to? (I notice that it says the -j option only takes effect for that call to make, and subsequent calls have to have -j added to them; I dont think the cmake generated makefile will do this for me, will it?) 2) When I get 'valid' source, what parameters were used in the config.h? Most importantly, was HAVE_CYGWIN_MAKE or HAVE_MKS_MAKE defined? Apologies of this seems tangential, but unless I am misunderstanding the CVS repository make hasn't been released for 2+ years so the change from Bill has never been released... ___ 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] Query about FindXXX files
On 2008-09-17 15:45- Leo Breebaart wrote:
So if the Cache is not the right way to pass information
'sideways' in your build tree, what is? I think I understand (but
please correct if I get it wrong -- I am new to CMake) that if I
call FIND_PACKAGE(TIFF) at a high enough level, i.e. at my top
level CMakeLists.txt, the TIFF_LIBRARIES var will be available to
all 'lower' level directories reached via ADD_SUBDIRECTORY.
Yes, you are correct.
But in this case, it still seems somehow wrong to me not to keep
the check where it belongs, i.e. with the application. But the
library is not a subdir from the application dir (and shouldn't
be -- it may be used elsewhere as well), so I still have that
'passing information sideways' problem. TIFF_INCLUDE_DIR is no
problem, because FIND_PACKAGE(TIFF) *does* put that one in the
cache...
I think you have answered your own question. Determine local things
locally and determine things that are going to be used in more than
one place in a higher level directory.
N.B. to keep our top-level CMakeLists.txt file from getting too cluttered
by general find commands, it is a nice idea to set CMAKE_MODULE_PATH in your
top-level directory, then include files from there.
e.g.,
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules)
include(anyname)
immediately includes CMake commands from cmake/modules/anyname.cmake just as
if they had been typed in the top-level CMakeLists.txt. Furthermore,
anyname.cmake itself can include other files from cmake/modules so that helps
you to keep everything nicely organized.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] multi-line definitions
Hi, Is it possible to write variable definition directives using multiple lines, i.e. I have a long definition string such as: SET (CMAKE_C_FLAGS_RELEASE -mcpu=arm7tdmi -std=gnu99 -fgnu89-inline - finline-functions -ffunction-sections -fdata-sections -fno-strict- aliasing -mno-thumb -Os -s -fomit-frame-pointer -DNDEBUG) How can I split this line (so that it fits into 80 column pages) ? Thanks, Manu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] using cmake with google's protocol buffers
Hi, I'm trying to add a special cmake rule to build google's protocol buffers, and I was hoping someone could help me do it. I've broken down the details of the protocol compiler here, so all that's missing is a cmake expert. I have some .proto files that live in the same directories as the source. I want to specify a rule that calls this: protoc DIR/SOMEFILE.proto --cpp_out=SOMEDIR SOMEDIR should probably be DIR/CMakeFiles/DIR.dir this will generate SOMEDIR/SOMEFILE.pb.h SOMEDIR/SOMEFILE.pb.cc I want to include SOMEFILE.pb.h in my source files and I want them to be found. I want to compile and link SOMEFILE.pb.cc automatically what is the easiest set of rules that I can use to extend cmake to do this? Thanks Neil ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] make -j and cmake
Jim Chaney wrote: Although the version of make available on the cmake website seems to work OK from the command line, when I then run it under Incredibuild (to move from parallel to distributed builds) I get a crash inside make.exe. I have spoken to Xoreax (the makers of Incredibuild) and they are interested but unable to assist, as the problem is inside make and not their product. The logical step then was to make my own debug version of make from the source, but I cannot get the same behaviour from a locally compiled make (using latest CVS as downloaded from Savannah) as I do with the version from the cmake website. So to the questions: 1) What modifications were made to the CVS of make? Is there a certain date I should sync to? (I notice that it says the -j option only takes effect for that call to make, and subsequent calls have to have -j added to them; I dont think the cmake generated makefile will do this for me, will it?) The fix allowed for C:/ to be a valid path. It had nothing to do with -j. Current CVS should have the fix, I don't have a date. 2) When I get 'valid' source, what parameters were used in the config.h? Most importantly, was HAVE_CYGWIN_MAKE or HAVE_MKS_MAKE defined? It was built as cygwin. You might want to look at this: http://sites.google.com/a/rwalker.com/cygwin/make-381-DOS It has the source as well. Apologies of this seems tangential, but unless I am misunderstanding the CVS repository make hasn't been released for 2+ years so the change from Bill has never been released... That is a cygwin issue. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
