[cmake-developers] [CMake 0011534]: PackageMaker install location customization is too restricted
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11534 == Reported By:Domagoj Saric Assigned To: == Project:CMake Issue ID: 11534 Category: CPack Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2010-11-29 05:56 EST Last Modified: 2010-11-29 05:56 EST == Summary:PackageMaker install location customization is too restricted Description: It should be possible to disable changing of the target driver/folder altogether as well as allow full (user) customization of the install location (include per-component, independent, target locations)... Please see the following post for more details: http://www.mail-archive.com/cm...@cmake.org/msg32844.html == Issue History Date ModifiedUsername FieldChange == 2010-11-29 05:56 Domagoj Saric New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] New blog post: Constraining Values with ComboBoxes in CMake (cmake-gui)
Read all about it: http://www.kitware.com/blog/home/post/82 Cheers, David Cole Kitware, Inc. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Relink on library rebuild dilema
Bill Hoffman bill.hoff...@... writes:
No need for all the complication...
If you already know where the library is going to be:
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
Then link directly to the full path:
target_link_libraries(main_target
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a)
Now the makefiles will depend on that file and it will relink when that
.a changes. This is why link_directories/*link_libraries without a
full path to the library is almost always a bad idea...
Sure enough, that works also! I have tried it before but did not realize that if
I want the target depend on a file instead of another target, not only do I have
to specify the full path but also the full filename so libkernel_executable.a
is necessary instead of kernel_executable. In the latter case CMake seems to
believe this is another target, tries to build it and fails. Now it makes
perfect sense, thanks for the help, my problem is solved.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] building using Visual C++ 64 bits edition
Dear all, I have just migrated to a brand new PC running Windows 7 home premium 64 bits (Intel proc) and I would like to compile a 64 bits version of my programs (that use VTK, ITK, FLTK). I have installed the 2010 express edition of Visual C++ and the SDK 7.1 that includes 64 bits compiler. I had a problem when configuring my ITK64 project using CMake and I am not sure whether it is a bug... Since I have found a solution, I share it! I had an error during the testCCompiler (see the error below this mail). I noticed that the SDK version used by Cmake was V7.0A while it doesn't contain the 64 bits of Cl.exe... I have just 'renamed' the directory (Ok, I know, bad solution but if you have a better one...) from V7.1 to V7.0A... and it worked. I managed to compile ITK3.20.0 64 bits version. Is it a bug from CMake? Do I had to remove the V7.0A? If yes, how to? Laurent. ___ Determining if the C compiler works failed with the following output: Change Dir: C:/Lib/ITK3.20.0bin64/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build Engine, Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporationÿ2007. Tous droits r,serv,s. La g,n,ration a d,marr, 29/11/2010 11:07:02. Projet C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj sur le noud 1 (cibles par d,faut). PrepareForBuild: Cr,ation du r,pertoire cmTryCompileExec.dir\Debug\. Cr,ation du r,pertoire C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\Debug\. InitializeBuildStatus: Cr,ation de cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild, car AlwaysCreate a ,t, sp,cifi,. ClCompile: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\CL.exe /c /Zi /nologo- /W3 /WX- /Od /Ob0 /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /FocmTryCompileExec.dir\Debug\\ /FdC:/Lib/ITK3.20.0bin64/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb /Gd /TC /errorReport:queue testCCompiler.c /Zm1000 Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. cl /c /Zi /nologo- /W3 /WX- /Od /Ob0 /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /FocmTryCompileExec.dir\Debug\\ /FdC:/Lib/ITK3.20.0bin64/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.pdb /Gd /TC /errorReport:queue testCCompiler.c /Zm1000 cl : Command line warning D9035: option 'nologo-' has been deprecated and will be removed in a future release [C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] testCCompiler.c ManifestResourceCompile: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo /focmTryCompileExec.dir\Debug\cmTryCompileExec.exe.embed.manifest.res cmTryCompileExec.dir\Debug\cmTryCompileExec_manifest.rc Link: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe /VERSION:0.0 /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /ManifestFile:cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.intermediate.manifest /MANIFESTUAC:level='asInvoker' uiAccess='false' /DEBUG /PDB:C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.pdb /SUBSYSTEM:CONSOLE /STACK:1000 /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:C:/Lib/ITK3.20.0bin64/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.lib /MACHINE:X64 cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.embed.manifest.res cmTryCompileExec.dir\Debug\testCCompiler.obj /machine:x64 /debug LINK : fatal error LNK1104: cannot open file 'kernel32.lib' [C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] G,n,ration du projet C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj termin,e (cibles par d,faut) -- ?CHEC. ?CHEC de la build. C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (cible par d,faut) (1) - (ClCompile cible) - cl : Command line warning D9035: option 'nologo-' has been deprecated and will be removed in a future release [C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (cible par d,faut) (1) - (Link cible) - LINK : fatal error LNK1104: cannot open file 'kernel32.lib' [C:\Lib\ITK3.20.0bin64\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] 1 Avertissement(s) 1 Erreur(s) Temps ,coul, 00:00:00.38 ___ Powered by www.kitware.com Visit other Kitware open-source projects at
Re: [CMake] How to apply the --as-needed linker flag?
On 28-11-2010 at 9:10, in message alpine.deb.2.00.1011272348290.11...@ybpnyubfg.ybpnyqbznva, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-11-28 06:39+0100 Michael Hertling wrote: On 11/27/2010 06:45 PM, Alan W. Irwin wrote: I just discovered that many Linux distros these days use the --as-needed Linux linker option by default. At first glance that option makes a lot of sense since it tends to reduce startup times. But I guess there are some caveats as well which is probably why CMake does not adopt this linker option by default for Linux builds. However, I would at least like to try this option for my own Linux builds without forcing it using target_link_libraries. Is it possible to specify linker options such as --as-needed using environment variables and/or -D options? On Linux, CMake takes account of the LDFLAGS environment variable for the initial configuration of the build directory, so saying LDFLAGS=-Wl,--as-needed cmake path/to/srcdir enables --as-needed for this build directory - forever. Thanks, Michael, that was exactly what I needed. I was completely unaware that environment variable worked for CMake despite many years of using CMake on Linux. Is the LDFLAGS environment variable documented for CMake anywhere? I couldn't find it in the documentation you get with cmake --help-full, and it is also not documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow you to specify general compiler flags in a convenient way are undocumented as well, and that is a real shame. 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). Hi Alan, You may find the following links of interest. They discuss the virtues and risks of using --as-needed in the light of underlinking and overlinking; and how to fix broken packages in distributions. http://wiki.mandriva.com/en/Overlinking http://wiki.mandriva.com/en/Underlinking http://www.gentoo.org/proj/en/qa/asneeded.xml Regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Relink on library rebuild dilema
On 11/29/2010 05:05 AM, Bill Hoffman wrote:
On 11/28/2010 3:19 AM, Sebastian Schaetz wrote:
Michael Hertlingmhertl...@... writes:
1) In the top-level CMakeLists.txt, you might say
SET_SOURCE_FILES_PROPERTIES(
main.cpp PROPERTIES OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
)
When libkernel_executable.a has changed, this results in recompiling
main.cpp - a penalty - and the desired relinking of main_target. If
main.cpp's recompilation is expensive you may possibly add an empty
cpp file to main_target's sources and impose the property on that.
Wow, those suggestions all sound great and I'm completely unfamiliar with
them
(so I think there's a good chance they will work). I will try them as soon as
possible! Thanks a lot for the suggestions.
No need for all the complication...
If you already know where the library is going to be:
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
Then link directly to the full path:
target_link_libraries(main_target
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a)
Now the makefiles will depend on that file and it will relink when that
.a changes. This is why link_directories/*link_libraries without a
full path to the library is almost always a bad idea...
Oops, the simplest solution at all. ~8) Thanks for pointing it out, Bill.
Perhaps, this is a good opportunity to ask a related question: Some
time ago, there has been an issue with special linker scripts which
are part of a project. Of course, one would like to see the linker
triggered when these scripts change, and the best solution I have
found so far is - just like suggested to the OP -
- a dummy source file to impose the OBJECT_DEPENDS property on, or
- a dummy static library that is invalidated when the scripts change
and (mis)used to force a dependency of the link line on the scripts.
Both alternatives are not really satisfying, so I wonder if there is any
smarter and more direct possibility to establish a file-level dependency
of the link line on an arbitrary file that's not mentioned as a library
in TARGET_LINK_LIBRARIES(). For Makefiles, this involves just a single
additional line.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake
Hi,
I don't have much time to spend on this but looking at qmake source
code I've found this files:
http://qt.gitorious.org/qt/qt/blobs/4.6-stable/mkspecs/common/symbian/symbian.conf
http://qt.gitorious.org/qt/qt/trees/4.6-stable/mkspecs/symbian-abld
I'm not sure but it could be useful to understand how qmake generate a
project for the symbian platform.
mkspecs contains the platform specific definitions.
Nicola Brisotto
2010/9/30 Alexander Neundorf a.neundorf-w...@gmx.net:
On Thursday 30 September 2010, Nicola Brisotto wrote:
I use Qt creator with cmake for desktop application and it work well. It
has support for out of source build, it populate the project browser with
you source and header, etc My main issue is not a full Qt Creator
integration. My first need is build with cmake from console.
Currently Qt support 2 toolchain: abdl and raptor.
I
http://www.paraview.org/Wiki/CMake_Cross_Compiling
After reading Wiley - Porting to the Symbian Platform Open Mobile
Development in C and C++, chapter 2.5.2 and 2.5.3 and some tutorial I
understand that abdl uses 3 kind of file: 1) one bdl.inf
2) one or more *.mpp file
3) optionally a pkg file
You process these files with a tool named 'bldmake' and will obtain a batch
file ('ABLD.BAT') and some makefiles that will build the application for
you.
This tool exists mainly because a Symbian application is usually built for
many platforms: the emulator, using a Microsoft X86 compiler,
as well as the real device using a gcc-derived ARM compiler.
The bldmake saves you from writing specially crafted makefiles for these
compilers and make utilities; also it allows for building many targets with
just a single command.
From the bld.inf, type:
bldmake bldfiles
Of course, you must have the PATH set correctly for the installation of the
SDK you are using. This command will look for the bld.inf, process it and the
related *.mmp, then generate a BATCH file named ABLD.BAT. Now you have all
you need to build your applications. Simply type:
abld build
This will build your application in all the available flavors.
Note that the target files are stored in a very deep directory structure,
and you are building both in debug and release versions for WINS (windows),
ARM4 (plain arm), ARMI (speed optimized arm), THUMB (size optimized ARM)!
But you can choose to build for only one target, and since it take less
time, you usually build ONLY for one version of one target. For example, to
build for the emulator only in the debug version, or for the device,
optimized for size, in release version, you type:
abld build wins udeb
abld buind thumb urel
Building for Windows is enough to start the emulator and run the
application in the emulated environment. Application files are compiled and
placed straight where the emulator can run it: no need to copy them in the
right location.
But for real devices, you have to pack everything in a .sis file for
installation, send it to the phone and install the application. You are
required to write a .pkg file to describe the installer, and then create it
with:
makesis file.pkg
this is a small example:
Here is a simple example of a bld.inf file:
PRJ_PLATFORMS
DEFAULT
PRJ_EXPORTS
..\inc\SoundTouch.h
..\inc\FIFOSamplePipe.h
..\inc\FIFOSampleBuffer.h
..\inc\STTypes.h
PRJ_MMPFILES
SoundTouch.mmp
This specifies that the project should generate makefiles for the default
platforms (currently WINSCW, ARMV5 and GCCE), export four header files and
build a single component which is specified in SoundTouch.mmp. The
corresponding MMP file looks like this:
TARGET SoundTouch.dll
TARGETTYPE dll
UID 0x108D 0x0839739D
CAPABILITY None
USERINCLUDE ..\inc
SYSTEMINCLUDE \epoc32\include \epoc32\include\stdapis
SYSTEMINCLUDE \epoc32\include\stdapis\sys
SYSTEMINCLUDE \epoc32\include\stdapis\stlport
SOURCEPATH ..\src
SOURCE SoundTouch.cpp AAFilter.cpp
SOURCE FIFOSampleBuffer.cpp FIRFilter.cpp
SOURCE RateTransposer.cpp TDStretch.cpp
LIBRARY euser.lib
LIBRARY libc.lib libm.lib libstdcpp.lib
Thanks for that summary, that's great.
Do we need a custom generator to recreate this process with cmake?
I started creating Symbian cmake files so that cmake can generate Makefiles
for Symbian, and got so far that I was able to compile and link a hello world
app.
The patch is from January and attached here:
http://public.kitware.com/Bug/view.php?id=8486
It's the one called Symbian.patch.
You can start and have a look at it.
It currently supports only one version of Symbian (the one I have), for
compiling for Symbian under Linux.
The detection of the version happens in Symbian-GNU-Common.cmake. If you
follow from there on, you should be able to figure out what needs to be done
for other versions of symbian.
The main
Re: [CMake] providing library information, what's the cmake way
Sorry for the late response, but your mail was simply to long for a
swift response...
On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote:
On 11/24/2010 04:51 PM, Johannes Zarl wrote:
About the components question again: I played around a bit, and I think I
now more or less have comprehended this. I guess for a package XXX with
components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
and then use a loop like this one in the XXXConfig.cmake file:
foreach( component ${XXX_FIND_COMPONENTS} )
if ( XXX_HAS_${component})
set ( XXX_${component}_FOUND TRUE )
else( XXX_HAS_${component})
if ( ${XXX_FIND_REQUIRED})
message(FATAL_ERROR Required component ${component} not
found!)
elseif ( NOT XXX_FIND_QUIETLY)
message(STATUS Component ${component} not found!)
endif ( ${XXX_FIND_REQUIRED})
endif ( XXX_HAS_${component})
endforeach( component )
Correct?
While that's a possible approach it lacks the invocation-specific
variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
some cases, these can't be assembled in a simple component-wise
manner, see below. Moreover, there are further questions w.r.t.
multi-component packages and their config files:
Does this mean that XXX_LIBRARIES etc. should normally incorporate the
settings for the components as well? IMO this can't work if you call
find_package several times with different components. Also, this would
make it impossible to link to the base library alone, i.e. without
the components...
- Does the config file provide the component-specific variables like
XXX_YYY_FOUND for each available component or for the requested ones
only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
approach, you can't. That's alright, but should be mentioned in the
package's documentation. Imagine the following scenario: There's one
installation of XXX for the native system and another one for cross
compiling purposes. The latter has YYY and ZZZ while the former has
YYY only. Due to FIND_PACKAGE()'s ability to search for config files
in various locations, such a coexistence is easily possible. Now, a
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
hold from the previous invocation? Both alternatives are fine, but the
user should know the score.
Thanks, I hadn't thought of this. So the code-snippet above should
contain a set ( XXX_${component}_FOUND ${component}-NOTFOUND ).
Besides, it's a good style to refer to any
component-related variables only if the particular component has been
requested explicitly.
Ok, so a better style would be to only set the XXX_HAS_* variables at
first (maybe unsetting them at the end of the config file?), and then
to conditionally set the XXX_YYY_INCLUDE_DIRS etc. if XXX_YYY_FOUND
is true.
- Handling of inter-component dependencies: Imagine the user just says
FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
enabled automatically the config file must know about the dependency
and cannot simply add the ZZZ-specific variables to the invocation-
specific ones; the YYY-specific variables must be mentioned, too.
I don't really see this as a problem. Although the code at hand lacks
support for this kind of dependencies, in most cases you won't need it.
And if you as the config file writer need it, you obviously know you
have dependencies and that you have to write code supporting those
dependencies.
Update/FYI: I just tried tried to write generic code to deal with
dependencies, and its not as straightforward as I thought it is. Assuming
that there are no circular dependencies, you could recursively add the
dependencies to the XXX_FIND_COMPONENTS variable and remove the duplicates
afterwards. Then you can use the above code to set XXX_*_FOUND, and
afterwards, you have to recursively add the libraries/defines/include_dirs
of the depended upon components to each component's includes (this
is the tricky part IMO). I guess it is far easier to write this in a
non-generic way...
- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables?
Generally speaking, I would say: yes. At least this is the way of the
least surprise for the user, as in sufficiently complex projects a
package may be included at different places with different arguments.
FIND_PACKAGE(XXX REQUIRED YYY)
FIND_PACKAGE(XXX COMPONENTS ZZZ)
Ah, this is how it's done. I was wondering why a call like
find_package(XXX COMPONENTS ZZZ REQUIRED YYY)
sets both XXX_YYY_REQUIRED and XXX_ZZZ_REQUIRED.
When turning towards find modules, the
Re: [CMake] Error using CMake 2.8.x, Visual Studio 2010, and multiple platform SDKs.
On 11/28/2010 10:59 PM, Bill Hoffman wrote: On 11/24/2010 5:02 PM, Ted Berg wrote: I'm seeing a reproducible failure generating Visual Studio 10 output on a system with the following installed: CMake 2.8.2 CMake 2.8.3 Visual Studio 2005 Visual Studio 2010 Program Files\Microsoft SDKs\Windows v6.1 v7.0A v7.1 To keep everything sane I use command files to set environment variables as needed, beyond the compiler specific command windows. In a VS 2010 command window, with an environment set to point at the V7.0A platform SDK, I can reliably create and build NMake projects. In that same window CMake errors out at Checking for working C compiler using: Visual Studio 10, claiming a broken compiler. Checking the CMakeFiles\CMakeErrors.log shows that while it's using the correct CL.exe, the rc.exe from the v6.1 platform sdk is being used. This rc.exe objects to the command line option /nologo somehow interpreting it as -ologo and terminating with a fatal error. If I move/rename the v6.1 platform sdk directory, CMake completes without issue. Is this a known issue, am I insane, or should I start assembling a sample project and logs? I am pretty sure CMake just used the rc.exe that is in the PATH. So, it sounds like your environment is not quite right. You are correct. It turns out that the problem was caused by having the v6.1 include/lib/bin paths prefixed to their respective Visual Studio 2005 Tools | Options | Projects and Solutions | VC++ Directories entries. Those directories are prefixed to the VS 2010 search directories, and I've not found a way to remove them in VS 2010. I cleared them out of VS 2005 and all was well. Thank you. -- ID: 0x9AAE10A5 Keyserver: pool.sks-keyservers.net Fingerprint: E79C 8FB2 D41D FCA3 410D 3D11 B5BD 5130 9AAE 10A5 signature.asc Description: OpenPGP digital signature ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] New blog post: Constraining Values with ComboBoxes in CMake (cmake-gui)
Read all about it: http://www.kitware.com/blog/home/post/82 Cheers, David Cole Kitware, Inc. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] providing library information, what's the cmake way
On 11/29/2010 at 14:28, Johannes Zarl johannes.z...@jku.at wrote: On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote: See [1] for a former discussion of several aspects regarding multi-component packages. [...] [1] http://www.mail-archive.com/cmake@cmake.org/msg28431.html Looks interesting. I will have to read that discussion... Ok. Now I that I have read that whole thread, I think I more or less agree with you, Michael. Also, I've found this mail from Brad King quite informative: http://www.mail-archive.com/cmake@cmake.org/msg28666.html Have a nice evening, Johannes -- Johannes Zarl Virtual Reality Services Johannes Kepler University Informationsmanagement Altenbergerstrasze 69 4040 Linz, Austria Phone: +43 732 2468-8321 johannes.z...@jku.at http://vrc.zid.jku.at ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Trouble with non standard Qt installation.
Hello. Our team uses the same Windows (VS) Qt build, but all the developers don't store it at the same place on their hard drive. So qmake.exe doesn't contain the good include, library, ... directories. On the FindQt4.cmake script of version 2.8.2 (line 770), the find_library call was using QT_LIBRARY_DIR variable to find the possible location of QtCore.lib, ... But on version 2.8.3, this module now queries qmake.exe to retrieve the library and includes path. This stuck us to the 2.8.2 version of CMake, since qmake doesn't return the good directories. How can we fix that? Thanks, Thibaut ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trouble with non standard Qt installation.
On Mon, Nov 29, 2010 at 1:35 PM, tibur tiburti...@gmail.com wrote: Hello. Our team uses the same Windows (VS) Qt build, but all the developers don't store it at the same place on their hard drive. So qmake.exe doesn't contain the good include, library, ... directories. On the FindQt4.cmake script of version 2.8.2 (line 770), the find_library call was using QT_LIBRARY_DIR variable to find the possible location of QtCore.lib, ... But on version 2.8.3, this module now queries qmake.exe to retrieve the library and includes path. This stuck us to the 2.8.2 version of CMake, since qmake doesn't return the good directories. How can we fix that? I am confused on what you are trying to fix. I mean on windows CMake rarely finds anything (since there is no standard path for libraries or development) unless it was one of the recent applications you built with CMake. However when it does not find a library, package ... just setting a variable to appropriate directory in CMakeGUI fixes the problem. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Trouble with non standard Qt installation.
On Mon, Nov 29, 2010 at 1:42 PM, John Drescher dresche...@gmail.com wrote: On Mon, Nov 29, 2010 at 1:35 PM, tibur tiburti...@gmail.com wrote: Hello. Our team uses the same Windows (VS) Qt build, but all the developers don't store it at the same place on their hard drive. So qmake.exe doesn't contain the good include, library, ... directories. On the FindQt4.cmake script of version 2.8.2 (line 770), the find_library call was using QT_LIBRARY_DIR variable to find the possible location of QtCore.lib, ... But on version 2.8.3, this module now queries qmake.exe to retrieve the library and includes path. This stuck us to the 2.8.2 version of CMake, since qmake doesn't return the good directories. How can we fix that? I am confused on what you are trying to fix. Oh. I see now. I think you need to have each developer build Qt on their system. -- John M. Drescher ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack: Different directory layout depending on generator
Hi everyone, This is basically a repeat question from what was asked in 2008 [1]. Is this possible now? To reiterate, I have a project to which I want to give my users an option to either install as a .deb file, or as a .tgz. in my tgz, I would like a layout such as foo-1.2.3.tgz: foo-1.2.3/README foo-1.2.3/ChangeLog foo-1.2.3/lib/libfoo.so foo-1.2.3/doc/... And in the deb, I want to install it like foo-1.2.3.deb: /usr/lib/libfoo.so /usr/share/doc/foo/README /usr/share/doc/foo/ChangeLog [1]: http://www.cmake.org/pipermail/cmake/2008-September/024117.html Thanks in advance /Johan ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Makefile to CMakeLists.txt (GTEST)
Hi,
/// - What I trying to do is to compile my unit test with google test
with cmake from a working Makefile.
/// - Here the Makefile
RRThread.o : $(USER_DIR)/RRThread.c $(USER_DIR)/RRThread.h
$(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/RRThread.c
UT_RRThread.o : $(UNITTEST_DIR)/UT_RRThread.cc \
$(USER_DIR)/RRThread.h $(GTEST_HEADERS)#
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -I$(USER_DIR) -c
$(UNITTEST_DIR)/UT_RRThread.cc
UT_RRThread : RRThread.o UT_RRThread.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
/// - Here how I thought of doing it with CMakeLists.txt:::
INCLUDE_DIRECTORIES(${GTEST_HEADER} ${USER_DIR})
ADD_EXECUTABLE(UT ${USER_DIR}RRThread.c ${UNIT_TEST_PATH}UT_RRThread.cc)
TARGET_LINK_LIBRARIES(UT pthread ${GTEST_LIB_PATH}gtest_main.a)
/// - My result:
Linking CXX executable UT
/usr/bin/cmake -E cmake_link_script CMakeFiles/UT.dir/link.txt
--verbose=1
/usr/bin/c++ CMakeFiles/UT.dir/common/RRThread.c.o
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o -o UT -rdynamic
-lpthread
/home/andromeda/rogue-research/3rdParty/gtest/trunk/Release/lib/gtest_main.a
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o: In function
`thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
/// - My question and my problem is:
Since I'm including the USER_DIR with INCLUDE_DIRECTORIES why is it
complaining about not finding reference that is in that header file?
Best Regards,
--
Kevyn-Alexandre Paré
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Makefile to CMakeLists.txt (GTEST)
Try adding the gtest.a library as well. Also, order does matter when you
are linking static libraries so you might need to play with the ordering.
Also, when you get some time, have a look at FindGTest.cmake. It may help
you simplify adding your tests.
On Mon, Nov 29, 2010 at 5:55 PM, Kevyn-Alexandre Paré
kap...@rogue-research.com wrote:
Hi,
/// - What I trying to do is to compile my unit test with google test
with cmake from a working Makefile.
/// - Here the Makefile
RRThread.o : $(USER_DIR)/RRThread.c $(USER_DIR)/RRThread.h
$(GTEST_HEADERS)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $(USER_DIR)/RRThread.c
UT_RRThread.o : $(UNITTEST_DIR)/UT_RRThread.cc \
$(USER_DIR)/RRThread.h $(GTEST_HEADERS)#
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -I$(USER_DIR) -c
$(UNITTEST_DIR)/UT_RRThread.cc
UT_RRThread : RRThread.o UT_RRThread.o gtest_main.a
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -lpthread $^ -o $@
/// - Here how I thought of doing it with CMakeLists.txt:::
INCLUDE_DIRECTORIES(${GTEST_HEADER} ${USER_DIR})
ADD_EXECUTABLE(UT ${USER_DIR}RRThread.c ${UNIT_TEST_PATH}UT_RRThread.cc)
TARGET_LINK_LIBRARIES(UT pthread ${GTEST_LIB_PATH}gtest_main.a)
/// - My result:
Linking CXX executable UT
/usr/bin/cmake -E cmake_link_script CMakeFiles/UT.dir/link.txt
--verbose=1
/usr/bin/c++ CMakeFiles/UT.dir/common/RRThread.c.o
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o -o UT -rdynamic
-lpthread
/home/andromeda/rogue-research/3rdParty/gtest/trunk/Release/lib/gtest_main.a
CMakeFiles/UT.dir/UnitTests/common/UT_RRThread.cc.o: In function
`thread_proc(void*)':
UT_RRThread.cc:(.text+0x28): undefined reference to `exitThread()'
/// - My question and my problem is:
Since I'm including the USER_DIR with INCLUDE_DIRECTORIES why is it
complaining about not finding reference that is in that header file?
Best Regards,
--
Kevyn-Alexandre Paré
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problems to find xmlrpc_server_abyss++.so on FreeBSD
Hi,
It's the first project i'm migrating from autotools to cmake,
and it's going really well, in 4 days it's almost done. \o/
The only issue I have now is following, i have this code
on my CMakeLists.txt:
find_package (XMLRPC REQUIRED abyss-server c++2)
message(STATUS xmlrpc-libs: ${XMLRPC_LIBRARIES})
When I run it on CentOS 5.5 with cmake 2.6.4 i got:
xmlrpc-libs: /usr/lib64/libxmlrpc_server_abyss++.so
and my binary is linked without problems, but, when I run
the same code on my FreeBSD 9.0-current amd64 with
cmake 2.8.3 I got:
xmlrpc-libs:
/usr/local/lib/libxmlrpc++.so;/usr/local/lib/libxmlrpc_server_abyss.so;/usr/local/lib/libxmlrpc_server.so;/usr/local/lib/libxmlrpc_abyss.so;/usr/local/lib/libxmlrpc.so;/usr/local/lib/libxmlrpc_util.so;/usr/local/lib/libxmlrpc_xmlparse.so;/usr/local/lib/libxmlrpc_xmltok.so
and my binary is not linked because xmlrpc_server_abyss++.so
is not on the list.
What am I missing here?
Ah, since i'm talking about FindXMLRPC, I used REQUIRED
param, like i showed above, but if it doesn't find xmlrpc
it shows an error message but don't stop, i needed to add
this:
if (NOT XMLRPC_FOUND)
message (FATAL_ERROR XMLRPC-C not found)
endif (NOT XMLRPC_FOUND)
Is it the expected behavior?
Thank you in advance
--
Renato Botelho
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problems to find xmlrpc_server_abyss++.so on FreeBSD
On Mon, Nov 29, 2010 at 9:20 PM, Renato Botelho rbga...@gmail.com wrote: Hi, It's the first project i'm migrating from autotools to cmake, and it's going really well, in 4 days it's almost done. \o/ The only issue I have now is following, i have this code on my CMakeLists.txt: find_package (XMLRPC REQUIRED abyss-server c++2) It's always the same, one entire day trying to figure it out and 5 seconds after sending this email i found, i just changed the order of components (c++2 abyss-server) and it detected my xmlrpc fine. It's fixed now. The other problem below still persists. Ah, since i'm talking about FindXMLRPC, I used REQUIRED param, like i showed above, but if it doesn't find xmlrpc it shows an error message but don't stop, i needed to add this: if (NOT XMLRPC_FOUND) message (FATAL_ERROR XMLRPC-C not found) endif (NOT XMLRPC_FOUND) Is it the expected behavior? It persists -- Renato Botelho ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] providing library information, what's the cmake way
On Tuesday 23 Nov 2010 5:27:56 pm Johannes Zarl wrote: Another somehow related topic seems to be import/export of targets. Should a LibraryConfig.cmake or FindLibrary.cmake file create imported targets for the library? Thanks for this thread. It has helped. However, i am still not clear about the use of the export/import feature. I thought that libraries built with cmake would not need to write their Find*.cmake or *Config.cmake modules as they could simply use the EXPORT feature. It would be really helpful if someone could explain the proper use of these features. And is there any documentation on how to create a LibraryConfig.cmake file with support for components? -- Cheers! Kishore ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.3-712-g2703aa2
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2703aa2f6c2fea451e0d98915f02014ff6b86f4c (commit)
via d0eb89c17b86dd583d315b15b8ca71e32561f49a (commit)
via bd44b2cc5bc4c0152e38474fd549f6b495d3b1b7 (commit)
via 7ce06dcc906ea3c6d39e663910df8c835f278ec6 (commit)
via 7a85200249b80b492753299b5ae423b233d38d7b (commit)
via 500711129ba286f07b10711fe9410fa52f3ef40c (commit)
via 537180ab19f2f50a57e3ea1c8bb94d61d186d9b0 (commit)
via 8bafdeb60edcb2c1f7b1fd8e18213129ccdf085a (commit)
from e7f6e52aace65c84499c49a59d370b5069cca70d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2703aa2f6c2fea451e0d98915f02014ff6b86f4c
commit 2703aa2f6c2fea451e0d98915f02014ff6b86f4c
Merge: e7f6e52 d0eb89c
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Mon Nov 29 13:01:16 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Nov 29 13:01:16 2010 -0500
Merge topic 'CPack-Bug11452-ComponentBreakage-v2' into next
d0eb89c CPack backward compatibility fix 2.8.3-2.8.2 (bug 11452)
bd44b2c KWSys Nightly Date Stamp
7ce06dc KWSys Nightly Date Stamp
7a85200 KWSys Nightly Date Stamp
5007111 KWSys Nightly Date Stamp
537180a KWSys Nightly Date Stamp
8bafdeb KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0eb89c17b86dd583d315b15b8ca71e32561f49a
commit d0eb89c17b86dd583d315b15b8ca71e32561f49a
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Mon Nov 29 18:57:24 2010 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Mon Nov 29 18:57:24 2010 +0100
CPack backward compatibility fix 2.8.3-2.8.2 (bug 11452)
One should set CPACK_ARCHIVE_COMPONENT_INSTALL=1 in order to
trigger component install for ARCHIVE generators
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx
b/Source/CPack/cmCPackArchiveGenerator.cxx
index 424c1a0..8bbf699 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -228,21 +228,23 @@ int cmCPackArchiveGenerator::PackageFiles()
PrepareGroupingKind();
- // CASE 1 : COMPONENT ALL-IN-ONE package
- // If ALL GROUPS or ALL COMPONENTS in ONE package has been requested
- // then the package file is unique and should be open here.
- if (allComponentInOne || (allGroupInOne (!this-ComponentGroups.empty(
-{
-return PackageComponentsAllInOne(allComponentInOne);
-}
- // CASE 2 : COMPONENT CLASSICAL package(s) (i.e. not all-in-one)
- // There will be 1 package for each component group
- // however one may require to ignore component group and
- // in this case you'll get 1 package for each component.
- else if ((!this-ComponentGroups.empty()) || (ignoreComponentGroup))
-{
-return PackageComponents(ignoreComponentGroup);
-}
+ if (SupportsComponentInstallation()) {
+// CASE 1 : COMPONENT ALL-IN-ONE package
+// If ALL GROUPS or ALL COMPONENTS in ONE package has been requested
+// then the package file is unique and should be open here.
+if (allComponentInOne || (allGroupInOne
(!this-ComponentGroups.empty(
+ {
+ return PackageComponentsAllInOne(allComponentInOne);
+ }
+// CASE 2 : COMPONENT CLASSICAL package(s) (i.e. not all-in-one)
+// There will be 1 package for each component group
+// however one may require to ignore component group and
+// in this case you'll get 1 package for each component.
+else if ((!this-ComponentGroups.empty()) || (ignoreComponentGroup))
+ {
+ return PackageComponents(ignoreComponentGroup);
+ }
+ }
// CASE 3 : NON COMPONENT package.
DECLARE_AND_OPEN_ARCHIVE(packageFileNames[0],archive);
@@ -278,5 +280,15 @@ int cmCPackArchiveGenerator::GenerateHeader(std::ostream*)
}
bool cmCPackArchiveGenerator::SupportsComponentInstallation() const {
- return true;
+ // The Component installation support should only
+ // be activated if explicitly requested by the user
+ // (for backward compatibility reason)
+ if (IsSet(CPACK_ARCHIVE_COMPONENT_INSTALL))
+{
+return true;
+}
+ else
+{
+return false;
+}
}
---
Summary of changes:
Source/CPack/cmCPackArchiveGenerator.cxx | 44 +++---
Source/kwsys/kwsysDateStamp.cmake|2 +-
2 files changed, 29 insertions(+), 17 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
