Re: [CMake] missing .S (assembly file) target

[Reto Glauser]

On Tue, 20 Sep 2011 19:11:58 +0200, Michael Hertling wrote:

After configuring, "make help" reveals:

% make help
The following are some of the valid targets for this Makefile:
... all (the default if no target is provided)
... clean
... depend
... edit_cache
... main
... mainxx
... rebuild_cache
... main.o
... main.i
... main.s
... mainxx.o
... mainxx.i
... mainxx.s

A "make main.s mainxx.s" results in:

% make main.s mainxx.s
...
Compiling C source to assembly CMakeFiles/main.dir/main.c.s
.../gcc -S .../main.c -o CMakeFiles/main.dir/main.c.s
...
Compiling CXX source to assembly CMakeFiles/mainxx.dir/mainxx.cxx.s
.../c++ -S .../mainxx.cxx -o CMakeFiles/mainxx.dir/mainxx.cxx.s

% ls CMakeFiles/main{,xx}.dir/*.s
CMakeFiles/main.dir/main.c.s  CMakeFiles/mainxx.dir/mainxx.cxx.s

Don't the *.s files appear as targets in your CMake-generated
Makefiles, or aren't they the files you are interested in?

Regards,

Michael


Thank you for providing the example, this works as expected. If one 
uses subdirectories for source files, one doesn't see the assembly 
target in the top-directory. To see the assembly targets, you have to cd 
into the subdirectory of the build.



___
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] CodeBlocks generator and source_group

[Alexander Neundorf]

On Tuesday, September 20, 2011 12:11:19 PM Tomasz Grobelny wrote:
> Is there any way to make cmake generate ‘’ element for Unit elements in CodeBlocks Project file (cbp)? I
> would expect it to happen by using 'SOURCE_GROUP("Source Files" FILES
> ${SOURCES})' construct but it does not work for me (should it?).

Please add a feature request for this on http://public.kitware.com/Bug , I'll 
assign it to me then.

Alex

___
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] linker default library path /usr/local/lib on OSX

[amine bezzarga]

Yes I think I get it, I tried that but it doesn't work either:
install_name_tool -change /usr/local/lib/libirrklang.dylib
./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/
./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib

Can you tell me, what can I do to fix the problem ?

On Tue, Sep 20, 2011 at 2:19 AM, Michael Jackson <
mike.jack...@bluequartz.net> wrote:

> Yes. Who ever built the irrklang library has set an "install_name" of
> /usr/local/lib on that library. So it does not matter where the library is
> located. OS X thinks it is in /usr/local/lib.
> You need to fix how that library is compiled and linked. Does that make
> it clear what is going on?
>
>
> -
> Mike Jackson 
> www.bluequartz.net
> Principal Software Engineer   
> mike.jack...@bluequartz.net
> BlueQuartz Software   Dayton, Ohio
> Sent from my mobile device.
>
> On Sep 19, 2011, at 19:56, amine bezzarga  wrote:
>
> Yeah, I tried the NO_DEFAULT_PATH option but without success.
> My target_link_library command look like this:
>
> target_link_libraries(${CMAKE_PROJECT_NAME} ${OGRE_LIBRARIES}
> ${OGRE_PLUGIN_LIBRARIES} ${Boost_LIBRARIES} ${OIS_LIBRARIES}
> ${IrrKlang_LIBRARIES})
>
> Here is the otool output of the sound library:
> $ otool -L
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
> (architecture ppc):
>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
> (compatibility version 1.0.0, current version 1.0.0)
>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
> 7.4.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 88.3.3)
> ./Dependencies/IrrKLangAudioEngine/bin/macosx-gcc/libirrklang.dylib
> (architecture i386):
>  /usr/local/lib/libirrklang.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
> (compatibility version 1.0.0, current version 1.0.0)
>  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
> 7.4.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 88.3.3)
>
> Does it help ?
>
>
> On Mon, Sep 19, 2011 at 1:56 PM, Michael Jackson 
> <
> mike.jack...@bluequartz.net> wrote:
>
>> My guess is that the audio library has an install path of /usr/local/lib
>> encoded in it. Try posting tue output of otool for the actual audio
>> library.
>>
>> -
>> Mike Jackson 
>> 
>> www.bluequartz.net
>> Principal Software Engineer   
>> 
>> mike.jack...@bluequartz.net
>> BlueQuartz Software   Dayton, Ohio
>> Sent from my mobile device.
>>
>> On Sep 18, 2011, at 23:38, Cristobal Navarro < 
>> axisch...@gmail.com> wrote:
>>
>> ok i get your point.
>> mmm. In others words you need something equivalent to rpath command, im
>> pretty sure cmake can handle this easily let me know if the following helps.
>>
>> have you tried adding more options to the find_library command ??
>> for example have you tried this (also, with the PATHS command just to be
>> sure):
>>
>> find_library(IrrKlang_LIBRARIES irrKlang
>> PATHS
>> ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc
>>  NO_DEFAULT_PATH
>>  )
>>
>> And what is your "target_link_libraries" command?
>>
>>
>>
>> On Sun, Sep 18, 2011 at 12:33 PM, amine bezzarga < 
>> 
>> abezz...@gmail.com> wrote:
>>
>>> The issue is not about finding the library at built time, event if my
>>> library is found in
>>> ${CMAKE_CURRENT_SOURCE_DIR}/Dependencies/IrrKLangAudioEngine/bin/macosx-gcc 
>>> and
>>> after building is done, my app is still looking for the library in
>>> /usr/local/lib at runtime as you can see with the otools output in my first
>>> message.
>>>
>>> I want to find a way to tell the linker to link the library from where it
>>> find it.
>>> Does it make sense ?
>>>
>>> On Sun, Sep 18, 2011 at 4:29 PM, Cristobal Navarro 
>>> <
>>> axisch...@gmail.com> wrote:
>>>
 yes

 you have to provide another option
 find_library( IrrKlang_LIBRARIES irrKlang PATHS >>> library>  ... )


 
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_library

 is this what you need?
 best regards
 Cristobal


 On Sun, Sep 18, 2011 at 10:16 AM, amine bezzarga < 
 
 abezz...@gmail.com> wrote:

> Hello guys,
>
> I added a sound library to my projec

[CMake] Reverted commit ... and CMake 2.8.6-rc4 planned for this Thursday

[David Cole]

On Tue, Sep 20, 2011 at 5:48 PM, Alan W. Irwin
 wrote:
> On 2011-09-20 16:21-0400 David Cole wrote:
>
>> I will be reverting the commits associated with the bad bug fix
>> mentioned here, so that we will end up with "equivalent to 2.8.5"
>> behavior with respect to this.
>>
>> We'll have to shoot for a real fix for next time.
>
> Thanks, Dave, for that good decision.
>
> BTW, I normally don't test the optimised case like I just did for
> 2.8.6-rc3.  Therefore as due diligence, I repeated that exact
> optimized test for 2.8.5, and all was well. So "equivalent to 2.8.5"
> should work here, but I will check once you get out the next RC just
> to be absolutely sure that 2.8.6 will be fine for PLplot.
>
> 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); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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
> __
>

This commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98c49a4a258214306db86eb5d7a2383d8b0561d1

reverts that commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd61be71401ef9e0a241562fc31539273084deff

I just reverted it and merged to 'next' -- tomorrow we'll be merging
the last-minute staged topics in 'next' over to 'master' for rc4,
Thursday, we plan to build and upload rc4, and then, assuming no
showstoppers are reported against rc4, we will do the final release
based on that within a week.


Thanks,
David
___
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 with CMake and gfortran on Windows XP

[Amber Simpson]

Hi All,

I'm trying to port a project to Windows from Ubuntu that uses C++ and
gFortran. When I run CMake, I get an error, the CMake output is below.
My CMakeLists.txt is attached.

I'm not sure if this is related to the bug reported here (and fixed
for ifort in the newest CMake):
http://itk.org/Bug/view.php?id=10351

My software versions:
Windows XP
Visual Studio 2005
CMake 2.8.5.20110918
gFortran 4.7.0

Thank you,
Amber


---

Check for working Fortran compiler using: Visual Studio 8 2005
Check for working Fortran compiler using: Visual Studio 8 2005  -- broken
CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40
(MESSAGE):
  The Fortran compiler "C:/Program Files/gfortran/bin/gfortran.exe" is not
  able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/src/IntraOpGUI/CMakeFiles/CMakeTmp



  Run Build Command:C:\PROGRA~1\MID05A~1\Common7\IDE\devenv.com
  CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec



  Microsoft (R) Visual Studio Version 8.0.50727.762.

  Copyright (C) Microsoft Corp 1984-2005.  All rights reserved.



  The application for project
  'C:\src\IntraOpGUI\CMakeFiles\CMakeTmp\cmTryCompileExec.vfproj' is not
  installed.



  Make sure the application for the project type (.vfproj) is installed.

  Invalid project



  Use:

  devenv [solutionfile | projectfile | anyfile.ext] [switches]



  The first argument for devenv is usually a solution file or project file.

  You can also use any other file as the first argument if you want to have
  the

  file open automatically in an editor.  When you enter a project file, the
  IDE

  looks for an .sln file with the same base name as the project file in the

  parent directory for the project file.  If no such .sln file exists, then
  the

  IDE looks for a single .sln file that references the project.  If no such
  single

  .sln file exists, then the IDE creates an unsaved solution with a default
  .sln

  file name that has the same base name as the project file.



  Command line builds:

  devenv solutionfile.sln /build solutionconfig [ /project projectnameorfile
  [ /projectconfig name ] ]

  Available command line switches:



  /BuildBuilds the solution or project with the specified 
solution

configuration.  For example "Debug".  If multiple platforms

are possible, the configuration name must be enclosed in quotes

and contain platform name.  For example: "Debug|Win32".

  /CleanDeletes build outputs.

  /Command  Starts the IDE and executes the command.

  /Deploy   Builds and then deploys the specified build 
configuration.

  /Edit Opens the specified files in a running instance of this

application.  If there are no running instances, it will

start a new instance with a simplified window layout.

  /LCID Sets the default language in the IDE for the UI.

  /Log  Logs IDE activity to the specified file for troubleshooting.

  /NoVSIP   Disables the VSIP developer's license key for VSIP 
testing.

  /Out  Appends the build log to a specified file.

  /Project  Specifies the project to build, clean, or deploy.

Must be used with /Build, /Rebuild, /Clean, or /Deploy.

  /ProjectConfigOverrides the project configuration specified in the
  solution

configuration.  For example "Debug".  If multiple platforms are

possible, the configuration name must be enclosed in quotes

and contain platform name.  For example: "Debug|Win32".

Must be used with /Project.

  /Rebuild  Cleans and then builds the solution or project with the

specified configuration.

  /ResetAddin   Removes commands and command UI associated with the specified
  Add-in.

  /ResetSettingsRestores the IDE's default settings, optionally resets 
to

the specified VSSettings file.

  /ResetSkipPkgsClears all SkipLoading tags added to VSPackages.

  /Run  Compiles and runs the specified solution.

  /RunExit  Compiles and runs the specified solution then closes the IDE.

  /SafeMode Launches the IDE in safe mode loading minimal windows.

  /Upgrade  Upgrades the project or the solution and all projects in it.

A backup of these files will be created as appropriate.  Please

see Help on 'Visual Studio Conversion Wizard' for more

information on the backup process.



  Product-specific switches:



  /debugexe Open the specified executable to be debugged.  The

remainder of the command line is passed to this

executable as its arguments.

  /useenv   Use PATH, INCLUDE, LIBPATH, and LIB environment 
variables

instea

Re: [CMake] CMake 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 16:21-0400 David Cole wrote:


I will be reverting the commits associated with the bad bug fix
mentioned here, so that we will end up with "equivalent to 2.8.5"
behavior with respect to this.

We'll have to shoot for a real fix for next time.


Thanks, Dave, for that good decision.

BTW, I normally don't test the optimised case like I just did for
2.8.6-rc3.  Therefore as due diligence, I repeated that exact
optimized test for 2.8.5, and all was well. So "equivalent to 2.8.5"
should work here, but I will check once you get out the next RC just
to be absolutely sure that 2.8.6 will be fine for PLplot.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__
___
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 2.8.6-rc3 ready for testing!

[Rolf Eike Beer]

Am Dienstag, 20. September 2011, 16:21:06 schrieb David Cole:
> On Tue, Sep 20, 2011 at 4:14 PM, Alan W. Irwin
> 
>  wrote:
> > On 2011-09-20 13:01-0700 Alan W. Irwin wrote:
> >> On 2011-09-20 11:56-0700 Alan W. Irwin wrote:
> >>> I don't want to overly dilute what seems to be your really important
> >>> message that there are serious build problems for cmake-2.8.6-rc3,
> >>> but
> >>> if nothing else, your post should galvanize lots of testing of
> >>> cmake-2.8.6-rc3 which is a "good thing".  When I did such build
> >>> testing myself, the optimized build of PLplot appears to be OK for
> >>> cmake-2.8.6-rc3 on at least my platform.
> >> 
> >> P.S. I should have mentioned that the bug concerned FindThreads.cmake,
> >> and the PLplot build system does use "find_package(Threads)" for the
> >> xwin device driver.  So I am a bit surprised I am not seeing the issue
> >> for an optimized build that includes that device driver.
> > 
> > P.P.S.  Strike that.  I found the issue at PLplot run-time, not build
> > time for CMake-2.8.6-rc3 (probably because the PLplot library
> > dynamically loads device drivers such as xwin).  So I strongly second
> > Orion's call for a fix before 2.8.6 is released.
> > 
> > Here is the evidence:
> > 
> > software@raven> examples/c/x01c -dev xwin
> > PLplot library version: 5.9.8
> > examples/c/x01c: symbol lookup error:
> > /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so: undefined
> > symbol: pthread_mutexattr_init
> > 
> > software@raven> ldd -r drivers/xwin.so |grep undefine
> > undefined symbol: pthread_mutexattr_settype (drivers/xwin.so)
> > undefined symbol: pthread_create(drivers/xwin.so)
> > undefined symbol: pthread_mutexattr_init(drivers/xwin.so)
> > undefined symbol: pthread_cancel(drivers/xwin.so)
> > undefined symbol: pthread_join  (drivers/xwin.so)
> > 
> > Thanks, Orion, for catching this problem.  Recently, I have become
> > quite lazy about testing cmake RC's because normally they just
> > work.  But cmake-2.8.6-rc3 is definitely an exception to that
> > rule and a general wakeup call for everyone to thoroughly test
> > the CMake RC's both at build time _and_ run time.

> I will be reverting the commits associated with the bad bug fix
> mentioned here, so that we will end up with "equivalent to 2.8.5"
> behavior with respect to this.
> 
> We'll have to shoot for a real fix for next time.

I think it's best to do for now. But for me it looks like the fix is indeed 
correct (for the pthreads part), but CheckFunctionExists isn't really 
reliable. I think I'll cook up some patches for this module that we can run 
through the dashboards and see when CheckFunctionExists does actually work 
(and when not). Then we can try to get some better code to detect the presence 
of functions.

Eike

P.S.: and I would really like if the mailing list footer could get a proper 
delimiter (i.e. "dash-dash-space") so it can be automatically stripped by 
every sane mail program when replying.

signature.asc
Description: This is a digitally signed message part.
___
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 2.8.6-rc3 ready for testing!

[David Cole]

On Tue, Sep 20, 2011 at 4:14 PM, Alan W. Irwin
 wrote:
> On 2011-09-20 13:01-0700 Alan W. Irwin wrote:
>
>> On 2011-09-20 11:56-0700 Alan W. Irwin wrote:
>>
>>> I don't want to overly dilute what seems to be your really important
>>> message that there are serious build problems for cmake-2.8.6-rc3, but
>>> if nothing else, your post should galvanize lots of testing of
>>> cmake-2.8.6-rc3 which is a "good thing".  When I did such build
>>> testing myself, the optimized build of PLplot appears to be OK for
>>> cmake-2.8.6-rc3 on at least my platform.
>>
>> P.S. I should have mentioned that the bug concerned FindThreads.cmake,
>> and the PLplot build system does use "find_package(Threads)" for the
>> xwin device driver.  So I am a bit surprised I am not seeing the issue
>> for an optimized build that includes that device driver.
>
> P.P.S.  Strike that.  I found the issue at PLplot run-time, not build
> time for CMake-2.8.6-rc3 (probably because the PLplot library
> dynamically loads device drivers such as xwin).  So I strongly second
> Orion's call for a fix before 2.8.6 is released.
>
> Here is the evidence:
>
> software@raven> examples/c/x01c -dev xwin
> PLplot library version: 5.9.8
> examples/c/x01c: symbol lookup error:
> /home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so: undefined
> symbol: pthread_mutexattr_init
>
> software@raven> ldd -r drivers/xwin.so |grep undefine
> undefined symbol: pthread_mutexattr_settype     (drivers/xwin.so)
> undefined symbol: pthread_create        (drivers/xwin.so)
> undefined symbol: pthread_mutexattr_init        (drivers/xwin.so)
> undefined symbol: pthread_cancel        (drivers/xwin.so)
> undefined symbol: pthread_join  (drivers/xwin.so)
>
> Thanks, Orion, for catching this problem.  Recently, I have become
> quite lazy about testing cmake RC's because normally they just
> work.  But cmake-2.8.6-rc3 is definitely an exception to that
> rule and a general wakeup call for everyone to thoroughly test
> the CMake RC's both at build time _and_ run time.
>
> 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); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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
> __
> ___
> 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
>

I will be reverting the commits associated with the bad bug fix
mentioned here, so that we will end up with "equivalent to 2.8.5"
behavior with respect to this.

We'll have to shoot for a real fix for next time.

Thanks,
David
___
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 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 13:01-0700 Alan W. Irwin wrote:


On 2011-09-20 11:56-0700 Alan W. Irwin wrote:


I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a "good thing".  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.


P.S. I should have mentioned that the bug concerned FindThreads.cmake,
and the PLplot build system does use "find_package(Threads)" for the
xwin device driver.  So I am a bit surprised I am not seeing the issue
for an optimized build that includes that device driver.


P.P.S.  Strike that.  I found the issue at PLplot run-time, not build
time for CMake-2.8.6-rc3 (probably because the PLplot library
dynamically loads device drivers such as xwin).  So I strongly second
Orion's call for a fix before 2.8.6 is released.

Here is the evidence:

software@raven> examples/c/x01c -dev xwin
PLplot library version: 5.9.8
examples/c/x01c: symbol lookup error:
/home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so: undefined
symbol: pthread_mutexattr_init

software@raven> ldd -r drivers/xwin.so |grep undefine
undefined symbol: pthread_mutexattr_settype (drivers/xwin.so)
undefined symbol: pthread_create(drivers/xwin.so)
undefined symbol: pthread_mutexattr_init(drivers/xwin.so)
undefined symbol: pthread_cancel(drivers/xwin.so)
undefined symbol: pthread_join  (drivers/xwin.so)

Thanks, Orion, for catching this problem.  Recently, I have become
quite lazy about testing cmake RC's because normally they just
work.  But cmake-2.8.6-rc3 is definitely an exception to that
rule and a general wakeup call for everyone to thoroughly test
the CMake RC's both at build time _and_ run time.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__
___
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 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 11:56-0700 Alan W. Irwin wrote:


I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a "good thing".  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.


P.S. I should have mentioned that the bug concerned FindThreads.cmake,
and the PLplot build system does use "find_package(Threads)" for the
xwin device driver.  So I am a bit surprised I am not seeing the issue
for an optimized build that includes that device driver.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__
___
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 2.8.6-rc3 ready for testing!

[Orion Poplawski]

On 09/20/2011 02:01 PM, Alan W. Irwin wrote:

On 2011-09-20 11:56-0700 Alan W. Irwin wrote:


I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a "good thing". When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.


P.S. I should have mentioned that the bug concerned FindThreads.cmake,
and the PLplot build system does use "find_package(Threads)" for the
xwin device driver. So I am a bit surprised I am not seeing the issue
for an optimized build that includes that device driver.

Alan


What is the output of the various "Looking for pthread_create" lines?  Often 
libraries like plplot pickup -pthread from libraries that they use.



--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
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 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 11:53-0600 Orion Poplawski wrote:


On 09/20/2011 08:38 AM, David Cole wrote:

On Tue, Sep 20, 2011 at 8:27 AM, Andrea Galeazzi  wrote:


Any news about when will it be finalized?




Soon... Stay tuned...



Not before a proper fix for http://public.kitware.com/Bug/view.php?id=12457 I 
hope.  As it stands, building KDE (and probably lots of other things) with 
2.8.6 is broken.  We've had to pull the rc builds out of Fedora rawhide.


Hi Orion:

Does "lots of other things" include PLplot (which for the benefit of
others here is one of the packages you maintain for Fedora)? It
appears to me from a quick read of the discussion in bug 12457, that
the predicted broken builds would occur for the optimized build case. 
Do I have that right?


Anyway, I tried a build of svn trunk PLplot here (my Debian squeeze
system) (with -DENABLE_ocaml=OFF for other reasons) with

export CFLAGS='-O3 -fvisibility=hidden'
export CXXFLAGS=$CFLAGS
export FFLAGS=$CFLAGS

and for cmake-2.8.6-rc3 there were no obvious problems with that
build.

I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a "good thing".  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__
___
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 2.8.6-rc3 ready for testing!

[Orion Poplawski]

On 09/20/2011 08:38 AM, David Cole wrote:

On Tue, Sep 20, 2011 at 8:27 AM, Andrea Galeazzi  wrote:


Any news about when will it be finalized?




Soon... Stay tuned...



Not before a proper fix for http://public.kitware.com/Bug/view.php?id=12457 I 
hope.  As it stands, building KDE (and probably lots of other things) with 
2.8.6 is broken.  We've had to pull the rc builds out of Fedora rawhide.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
___
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] add_custom_command and DEPENDS

[Michael Hertling]

On 09/20/2011 07:00 PM, Talin wrote:
> After several years of working with CMake, I have to say that I still do not
> understand the behavior of the DEPENDS clause in add_custom_command.
> 
> The main problem is a fairly simple one: I have an add_custom_command in one
> subdirectory, the output of which is needed by an add_custom_command in
> another subdirectory. Since add_custom_command can't refer to targets in
> other directories, I have followed the advice of various experts (on this
> list and on stackoverflow) and made additional targets via
> add_custom_target, in both subdirectories.
> 
> So in directory A, I have an add_custom_command which generates a file, and
> then I have an add_custom_target which depends on that file. In directory B,
> I have another custom target which uses add_dependencies to add a dependency
> to the custom target defined in A. Finally, I have an add_custom_command
> which has a DEPENDS clause adding a dependency to the target defined in that
> directory.
> 
> It's the last step that doesn't work - it says "No rule to make target
> , needed by .  Stop." Even though  is
> defined earlier in the same CMakeLists.txt file.
> 
> According to my reading of the CMake documentation, this should work
> (although the docs are quite confusing on this point). Here's what the doc
> says about the DEPENDS clause of add_custom_command: "If DEPENDS specifies
> any target (created by an ADD_* command) a target-level dependency is
> created to make sure the target is built before any target using this custom
> command." I'm assuming that the words "specifies any target" means that you
> can pass the name of a target as an argument to DEPENDS. If that's not what
> it means, please tell me.
> 
> Caveat: I'm still working with 2.8.3 - I see that generator expressions in
> 2.8.4 would solve my problems, but at the moment I'm stuck with the version
> that Ubuntu distributes.
> 
> In any case, I've been struggling with this specific problem off and on for
> over 3 years, asking for help on various forums, and I've never found an
> answer that actually works for me.

See [1] and upgrade; the generator expressions per se are worth the effort.

Regards,

Michael

[1] http://public.kitware.com/Bug/view.php?id=12057
___
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] missing .S (assembly file) target

[Michael Hertling]

On 09/20/2011 08:46 AM, Reto Glauser wrote:
> Hi
> 
> I don't see the .S targets (for C/CXX files) which used to be there. I 
> would like to look at the assembly files of the C/CXX files.
> 
> I'm on
> 
> GNU/Linux
> GCC-4.3.4
> CMake-2.8.2

With CMake 2.8.5 on Linux, I can't confirm this:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ASSEMBLER C CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/mainxx.cxx "int main(void){return 0;}\n")
ADD_EXECUTABLE(mainxx mainxx.cxx)

After configuring, "make help" reveals:

% make help
The following are some of the valid targets for this Makefile:
... all (the default if no target is provided)
... clean
... depend
... edit_cache
... main
... mainxx
... rebuild_cache
... main.o
... main.i
... main.s
... mainxx.o
... mainxx.i
... mainxx.s

A "make main.s mainxx.s" results in:

% make main.s mainxx.s
...
Compiling C source to assembly CMakeFiles/main.dir/main.c.s
.../gcc -S .../main.c -o CMakeFiles/main.dir/main.c.s
...
Compiling CXX source to assembly CMakeFiles/mainxx.dir/mainxx.cxx.s
.../c++ -S .../mainxx.cxx -o CMakeFiles/mainxx.dir/mainxx.cxx.s

% ls CMakeFiles/main{,xx}.dir/*.s
CMakeFiles/main.dir/main.c.s  CMakeFiles/mainxx.dir/mainxx.cxx.s

Don't the *.s files appear as targets in your CMake-generated
Makefiles, or aren't they the files you are interested in?

Regards,

Michael

> Adding
> 
> enable_language(ASM)
> SET (CMAKE_C_CREATE_ASSEMBLY_SOURCE "  -S 
>  -o ")
> 
> before the project doesn't help.
> 
> Any ideas?
> 
> Thanks
___
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] add_custom_command and DEPENDS

[Talin]

After several years of working with CMake, I have to say that I still do not
understand the behavior of the DEPENDS clause in add_custom_command.

The main problem is a fairly simple one: I have an add_custom_command in one
subdirectory, the output of which is needed by an add_custom_command in
another subdirectory. Since add_custom_command can't refer to targets in
other directories, I have followed the advice of various experts (on this
list and on stackoverflow) and made additional targets via
add_custom_target, in both subdirectories.

So in directory A, I have an add_custom_command which generates a file, and
then I have an add_custom_target which depends on that file. In directory B,
I have another custom target which uses add_dependencies to add a dependency
to the custom target defined in A. Finally, I have an add_custom_command
which has a DEPENDS clause adding a dependency to the target defined in that
directory.

It's the last step that doesn't work - it says "No rule to make target
, needed by .  Stop." Even though  is
defined earlier in the same CMakeLists.txt file.

According to my reading of the CMake documentation, this should work
(although the docs are quite confusing on this point). Here's what the doc
says about the DEPENDS clause of add_custom_command: "If DEPENDS specifies
any target (created by an ADD_* command) a target-level dependency is
created to make sure the target is built before any target using this custom
command." I'm assuming that the words "specifies any target" means that you
can pass the name of a target as an argument to DEPENDS. If that's not what
it means, please tell me.

Caveat: I'm still working with 2.8.3 - I see that generator expressions in
2.8.4 would solve my problems, but at the moment I'm stuck with the version
that Ubuntu distributes.

In any case, I've been struggling with this specific problem off and on for
over 3 years, asking for help on various forums, and I've never found an
answer that actually works for me.

-- 
-- Talin
___
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, iOS and .xib compilation

[David Cole]

I recently added a test to the CMake test suite that demonstrates how
to build a very rudimentary iOS app (a simple skeletal navigation bar
app, mostly generated by the "Xcode new project" dialog...)

It can be found at:
CMake/Tests/iOSNavApp

in the current checkout of git 'master' and 'next'

It is not included in the CMake test suite by default because most of
our dashboard Macs are not set up for iOS dev work by default.

I have tested it manually using the Xcode generator. The point of this
recent work was focused on getting "simulator" and "device" builds
both working within the same Xcode project at the same time, and
allowing the developer to switch back and forth between them in the
Xcode UI.

There are *.xib files in this project, and they are included simply by
adding them as source files to add_executable.

I've not used a makefile generator or a cross-compile-via-makefiles
technique with this sample project at all.

Perhaps you could take a look at the sources for the iOSNavApp test
application, and see if there's anything done in that project that you
could adapt for your needs.

The iOS support in CMake is still pretty bleeding edge -- let me know
if there's anything we can do to improve how it works from your
perspective.


Thanks,
David


On Tue, Sep 20, 2011 at 11:25 AM, Daniel Dekkers  wrote:
> Hi,
>
> I'm really having a hard time creating a CMake setup for iOS.
>
> After...
> - the toolchain files for cross-compiling,
> - the Settings.bundle,
> - the Info.plist file,
> - the provisioning profiles,
> - the entitlements,
> ...the latest chapter consists of the Interface Builder .xib files.
>
> An iOS application bundle needs a .nib file that is compiled from a .xib file 
> and added to the application bundle. I've got a script for that:
>
>                # We need to compile the interface builder *.xib files to 
> *.nib files to add to the bundle
>                # Make sure we can find the 'ibtool' program. If we can NOT 
> find it we skip generation of this project
>                FIND_PROGRAM( IBTOOL ibtool HINTS "/usr/bin" 
> "${OSX_DEVELOPER_ROOT}/usr/bin" )
>                if ( ${IBTOOL} STREQUAL "IBTOOL-NOTFOUND" )
>                        MESSAGE( SEND_ERROR "ibtool can not be found" )
>                ENDIF()
>
>                # Compile the .xib files using the 'ibtool' program with the 
> destination being the app package
>                FOREACH( xib ${RSRC_IOS_XIB_FILES} )
>                        ADD_CUSTOM_COMMAND( TARGET ${APP_NAME} POST_BUILD
>                                COMMAND ${IBTOOL} --errors --warnings 
> --notices --output-format human-readable-text
>                                        --compile
>                                        
> ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${RT_APP_NAME}.app/${xib}.nib 
> # iOS uses a flat hierarchy, place directly under .app
>                                        ${APP_ROOT}/rsrc/apple/ios/${xib}.xib
>                                        COMMENT "Compiling 
> ${APP_ROOT}/rsrc/apple/ios/${xib}.xib")
>                ENDFOREACH()
>
> But once I use the script. I constantly receive a "A signed resource has been 
> added, modified, or deleted." error when running on the device.
> This makes some sense, because all the files in the bundle are codesigned and 
> adding a new .nib file for every build might give signing problems.
>
> But I'm running out of ideas how to fix this.
> Any suggestions?
> Or, more general... is there anyone else who is walking, or has walked, this 
> CMake/iOS path?
>
> Kind Regards,
>
> Daniel Dekkers
>
>
>
> ___
> 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
>
___
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] CMake, iOS and .xib compilation

[Daniel Dekkers]

Hi,

I'm really having a hard time creating a CMake setup for iOS.

After...
- the toolchain files for cross-compiling, 
- the Settings.bundle,
- the Info.plist file,
- the provisioning profiles, 
- the entitlements,
...the latest chapter consists of the Interface Builder .xib files.

An iOS application bundle needs a .nib file that is compiled from a .xib file 
and added to the application bundle. I've got a script for that:

# We need to compile the interface builder *.xib files to *.nib 
files to add to the bundle
# Make sure we can find the 'ibtool' program. If we can NOT 
find it we skip generation of this project
FIND_PROGRAM( IBTOOL ibtool HINTS "/usr/bin" 
"${OSX_DEVELOPER_ROOT}/usr/bin" )
if ( ${IBTOOL} STREQUAL "IBTOOL-NOTFOUND" )
MESSAGE( SEND_ERROR "ibtool can not be found" )
ENDIF()

# Compile the .xib files using the 'ibtool' program with the 
destination being the app package
FOREACH( xib ${RSRC_IOS_XIB_FILES} )
ADD_CUSTOM_COMMAND( TARGET ${APP_NAME} POST_BUILD
COMMAND ${IBTOOL} --errors --warnings --notices 
--output-format human-readable-text
--compile

${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${RT_APP_NAME}.app/${xib}.nib # 
iOS uses a flat hierarchy, place directly under .app
${APP_ROOT}/rsrc/apple/ios/${xib}.xib
COMMENT "Compiling 
${APP_ROOT}/rsrc/apple/ios/${xib}.xib")
ENDFOREACH()

But once I use the script. I constantly receive a "A signed resource has been 
added, modified, or deleted." error when running on the device.
This makes some sense, because all the files in the bundle are codesigned and 
adding a new .nib file for every build might give signing problems.

But I'm running out of ideas how to fix this.
Any suggestions?
Or, more general... is there anyone else who is walking, or has walked, this 
CMake/iOS path?

Kind Regards,

Daniel Dekkers



___
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] VS2005: CMAKE_CXX_FLAGS not used when project() is placed after definition

[Michael Hertling]

On 09/20/2011 03:40 PM, Jens Auer wrote:
> Hi,
> 
> I encountered a problem with CMAKE_CXX_FLAGS and the place in the 
> CMakeLists.txt where the project() command is placed. Consider two 
> CMakeLists.txt files, the first containing
>   SET(CMAKE_CXX_FLAGS "/EHa /O2")
> 
>   project(CMAKE_BUG)
> 
>   add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
> 
> And the second containing
> 
>   project(CMAKE_BUG)
> 
>   SET(CMAKE_CXX_FLAGS "/EHa /O2")
> 
>   add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
> 
> When I run cmake 2.8.5 on both files, the exception handling option differs. 
> For the first file, it is set to 1 in the generated VS project file, which 
> means /Ehsc, the default. The second file generates the intended project file 
> with windows structured exceptions enabled.
> 
> I only checked the generated VS2005 files, so I don't know if this is an 
> issue of this specific generator or a more global one.
> 
> Best regards,
>   Jens

The PROJECT() command has significant side effects, e.g. for C++
projects, it loads Modules/CMakeCXXInformation.cmake containing:

SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_INIT}" CACHE STRING
 "Flags used by the compiler during all build types.")

If CMAKE_CXX_FLAGS has no value in the cache before, this command will
write to the cache *and* to the current scope, see [1]. Thus, it will
overwrite the value provided in the CMakeLists.txt in the first case.
In the second case, the CMakeLists.txt file provides the definitive
value in the current scope which will be in effect afterwards.

IMO, it's best to have PROJECT() as one of the very first commands
in CMakeLists.txt files, and to only put other commands before it
if one really knows about the consequences.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg29869.html
___
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] VS2005: CMAKE_CXX_FLAGS not used when project() is placed after definition

[Rolf Eike Beer]

> Hi,
>
> I encountered a problem with CMAKE_CXX_FLAGS and the place in the
> CMakeLists.txt where the project() command is placed. Consider two
> CMakeLists.txt files, the first containing
>   SET(CMAKE_CXX_FLAGS "/EHa /O2")
>
>   project(CMAKE_BUG)
>
>   add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
>
> And the second containing
>
>   project(CMAKE_BUG)
>
>   SET(CMAKE_CXX_FLAGS "/EHa /O2")
>
>   add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")
>
> When I run cmake 2.8.5 on both files, the exception handling option
> differs. For the first file, it is set to 1 in the generated VS project
> file, which means /Ehsc, the default. The second file generates the
> intended project file with windows structured exceptions enabled.
>
> I only checked the generated VS2005 files, so I don't know if this is an
> issue of this specific generator or a more global one.

PROJECT() initializes a bunch of stuff, e.g. it does the compiler
detection and sets the default flags. So what you are seeing is absolutely
expected behaviour.

Eike
___
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 2.8.6-rc3 ready for testing!

[David Cole]

On Tue, Sep 20, 2011 at 8:27 AM, Andrea Galeazzi  wrote:
> David Cole ha scritto:
>>
>> The CMake 2.8.6 release candidate stream continues! You can find the
>> source and binaries here:
>> http://www.cmake.org/files/v2.8/?C=M;O=D
>>
>> This email is also available on the Kitware blog at
>> http://www.kitware.com/blog/home/post/165
>>
>> If you want to test this out and ask for a fix, do it soon, or hold your
>> peace till the next release! I expect we will finalize the 2.8.6 release
>> by mid-September.
>>
>> This release candidate we do not have pre-built binaries for the
>> SunOS anymore. As mentioned on the CMake mailing list recently, our
>> Sun hardware has bitten the proverbial dust.
>>
>> However, we are now providing two sets of installers for the Mac.
>> The "Darwin" versions are for Mac OSX 10.4 and later, and are "ppc;i386"
>> universal binaries. The "Darwin64" versions are for 10.6 and later,
>> and are "x86_64;i386" universal binaries.
>>
>> Following is the list of changes in this release. Since we switched to
>> git, this list is now the 'git log' one line summary written by the
>> named CMake developers.
>>
>> Please try this version of CMake on your projects and report any
>> issues to the list or the bug tracker.
>>
>> Happy building!
>> -Dave
>>
>>
>> Changes in CMake 2.8.6-rc3 (since 2.8.6-rc2)
>> 
>> Alexey Ozeritsky (2):
>>      FindBLAS/LAPACK fixes
>>      FindBLAS/LAPACK fixes
>>
>> Andreas Schneider (1):
>>      Modules: Add support for more java archives in add_jar().
>>
>> Björn Ricks (4):
>>      Search for the installed python interpreter first
>>      Determine python version
>>      Update documentation of FindPythonInterp.cmake
>>      Use FIND_PACKAGE_HANDLE_STANDARD_ARGS second mode
>>
>> Brad King (5):
>>      VS: Map per-source Fortran flags to IDE options
>>      VS: Map Fortran free- and fixed-format flags to IDE options
>>      Fortran: Add support for free- and fixed-form flags
>>      Xcode: Honor Fortran_FORMAT target and source file property
>>      Set CMAKE__COMPILER_ID for VS generators
>>
>> David Cole (8):
>>      KWSys: Remove always-true dir_only parameter
>>      KWSys: Add symlinks to directories as files (#12284)
>>      FindPackageMessage: Eliminate new lines in cache entries
>>      FindPackageMessage: Eliminate new lines using REGEX REPLACE
>>      CMake: Add SaveCache at the end of successful Generate calls
>>      Suppress Qt warning for dashmacmini5 builds
>>      Suppress Qt warning for dashmacmini5 builds
>>      Tests: Look for "Illegal" or "SegFault" in the output
>>
>> Eric NOULARD (2):
>>      CPack  fix #12366 components RPM packages have the same package name
>>      CPackRPM fix #12305, include directories in RPM package
>>
>> Johan Björk (5):
>>      Xcode: No spaces in makefile target names (#12370)
>>      CMake: Write symlinks to directories as files in archives (#12284)
>>      CPack: Do not recurse through directory symlinks (#12284)
>>      Xcode: Do not emit the ZERO_CHECK target more than once
>>      Xcode: Honor -g0 to disable debugging (#12377)
>>
>> Johannes Stallkamp (1):
>>      CTest: Fixed valgrind output parsing (#12260)
>>
>> Matt McCormick (1):
>>      CMake: Remove documentation for -E build (#12446)
>>
>> Stephen Kelly (2):
>>      Add some more unit tests.
>>      Don't put what some compilers consider junk at the end of the line.
>>
>> Thomas Jarosch (3):
>>      CTest: Fix memory leaks on error
>>      Fix file() command descriptor leak on error
>>      ccmake: Fix off-by-one memory access error
>> ___
>> 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
>>
>
> Any news about when will it be finalized?
>
>

Soon... Stay tuned...
___
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] not found library with package configuration files and changed CMAKE_INSTALL_PREFIX

[Michael Hertling]

On 09/20/2011 11:26 AM, Alexander Dahl wrote:
> Hello there, 
> 
> after using FindFOO.cmake scripts for our own projects for a long time
> I'm trying to migrate this to the "real" CMake approach of package
> configuration files. Therefor I read chapter 5.7 of the book »Mastering
> CMake« and two HowTos [1] [2] on the web merging all of these in some
> files. I have own shared C library "foo" and one C command line tool
> "bar" and try to build this on Ubuntu Lucid 10.04 with a self compiled
> cmake 2.8.4.
> 
> This works fine as long as I don't change CMAKE_INSTALL_PREFIX (with
> `make edit_cache` or earlier when calling `cmake
> -DCMAKE_INSTALL_PREFIX=/some/path /path/to/src`) and it is /usr/local –
> however when changing this to /home/adahl/usr (or any other non standard
> path) linking the library fails although the include files are still
> found (FOO_DIR is correctly set to /home/adahl/usr/lib/cmake/foo).
> 
> I'll show my CMakeList.txt files and the package configuration stuff,
> maybe someone could have a look and point me to my errors.
> 
> In project "foo" which builds a shared C library:
> 
> CMakeLists.txt:
> 
>   4 project(foo)
>   5
>   6 cmake_minimum_required(VERSION 2.8)
>   7
>   8 set(PACKAGE_MAJOR_VERSION "0")
>   9 set(PACKAGE_MINOR_VERSION "1")
>  10 set(PACKAGE_BUILD_VERSION "0")
>  11 set(PACKAGE_VERSION
> "${PACKAGE_MAJOR_VERSION}.${PACKAGE_MINOR_VERSION}.${PACKAGE_BUILD_VERSION}"
>)
>  12
>  13 add_subdirectory("inc")
>  14 add_subdirectory("src")
>  15
>  16 configure_file(
>  17 ${CMAKE_CURRENT_SOURCE_DIR}/foo-config.cmake.in
>  18 ${CMAKE_CURRENT_BINARY_DIR}/foo-config.cmake @ONLY
>  19 )
>  20 configure_file(
>  21 ${CMAKE_CURRENT_SOURCE_DIR}/foo-config-version.cmake.in
>  22 ${CMAKE_CURRENT_BINARY_DIR}/foo-config-version.cmake @ONLY
>  23 )
>  24 install(FILES
>  25 ${CMAKE_CURRENT_BINARY_DIR}/foo-config.cmake
>  26 ${CMAKE_CURRENT_BINARY_DIR}/foo-config-version.cmake
>  27 DESTINATION "lib/cmake/${PROJECT_NAME}"
>  28 )
> 
> foo-config.cmake.in:
> 
>   4 get_filename_component(_dir "${CMAKE_CURRENT_LIST_FILE}" PATH)
>   5 get_filename_component(_prefix "${_dir}/../../.." ABSOLUTE)
>   6 include("${_dir}/@PROJECT_NAME@-targets.cmake")
>   7 set(FOO_INCLUDE_DIRS "${_prefix}/include/@PROJECT_NAME@")
> 
> foo-config-version.cmake.in:
> 
>   4 set(PACKAGE_VERSION "@PACKAGE_VERSION@")
>   5
>   6 if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}")
>   7 set(PACKAGE_VERSION_COMPATIBLE FALSE)
>   8 else()
>   9 set(PACKAGE_VERSION_COMPATIBLE TRUE)
>  10 if ("${PACKAGE_VERSION}" VERSION_EQUAL
> "${PACKAGE_FIND_VERSION}")
>  11 set(PACKAGE_VERSION_EXACT TRUE)
>  12 endif()
>  13 endif()
> 
> inc/CMakeLists.txt:
> 
>   4 install(FILES
>   5 foo.h
>   6 DESTINATION "include/${PROJECT_NAME}"
>   7 )
> 
> src/CMakeLists.txt:
> 
>   4 set(FOO_SRC
>   5 foo.c
>   6 )
>   7
>   8 include_directories(
>   9 "${PROJECT_SOURCE_DIR}/inc"
>  10 )
>  11
>  12 add_library(${PROJECT_NAME}-shared SHARED ${FOO_SRC})
>  13 set_target_properties(${PROJECT_NAME}-shared PROPERTIES
>  14 OUTPUT_NAME ${PROJECT_NAME}
>  15 SOVERSION   ${PACKAGE_MAJOR_VERSION}
>  16 VERSION ${PACKAGE_VERSION}
>  17 )

This leaves the target named "foo-shared", not "foo"; the latter is
just the base name of the target's disk file, i.e. libfoo.so.0.1.0.

>  18 install(TARGETS ${PROJECT_NAME}-shared DESTINATION "lib" EXPORT
> ${PROJECT_NAME}-targets)
>  19 install(EXPORT ${PROJECT_NAME}-targets DESTINATION
> "lib/cmake/${PROJECT_NAME}")

The foo-targets.cmake file contains "foo-shared" as imported target,
and it is this name that must be supplied to TARGET_LINK_LIBRARIES().
Besides, the DESTINATION clause of INSTALL() should be qualified with
ARCHIVE/LIBRARY/RUNTIME/..., and EXPORT must precede DESTINATION then.

> This allows successful build of the library with all files installed
> where they should be, at least binaries and header files. The package
> configuration files are installed like this:
> 
> % ls -l /home/adahl/usr/lib/cmake/foo
> insgesamt 16
> -rw-r--r-- 1 adahl adahl  248 2011-09-20 11:09 foo-config.cmake
> -rw-r--r-- 1 adahl adahl  334 2011-09-20 11:09 foo-config-version.cmake
> -rw-r--r-- 1 adahl adahl  924 2011-09-20 11:09 foo-targets.cmake
> -rw-r--r-- 1 adahl adahl 1041 2011-09-20 11:09
> foo-targets-noconfig.cmake
> 
> Now first I build this library like this:
> 
> ~/Work/build/libfoo % cmake -DCMAKE_INSTALL_PREFIX=/home/adahl/usr
> ../../src/libfoo
> ~/Work/build/libfoo % make
> ~/Work/build/libfoo % make install
> 
> No problem so far, but when building the cli tool »bar« like this:
> 
> ~/Work/build/bar % cmake -DCMAKE_INSTALL_PREFIX=/home/adahl/usr
> ../../src/bar
> ~/Work/build/bar % make
> 
> This fails like this:
> 
> Linking C executable bar
> /usr/bin/ld: cannot find -lfoo

The "-lfoo" notation instead of a full path is a typical hint that CMake
doesn't recognize "foo" as an [imported] target but as

[CMake] VS2005: CMAKE_CXX_FLAGS not used when project() is placed after definition

[Jens Auer]

Hi,

I encountered a problem with CMAKE_CXX_FLAGS and the place in the 
CMakeLists.txt where the project() command is placed. Consider two 
CMakeLists.txt files, the first containing
SET(CMAKE_CXX_FLAGS "/EHa /O2")

project(CMAKE_BUG)

add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")

And the second containing

project(CMAKE_BUG)

SET(CMAKE_CXX_FLAGS "/EHa /O2")

add_executable(testEHa "c:/work/tmp/cmake_eha/test.cpp")

When I run cmake 2.8.5 on both files, the exception handling option differs. 
For the first file, it is set to 1 in the generated VS project file, which 
means /Ehsc, the default. The second file generates the intended project file 
with windows structured exceptions enabled.

I only checked the generated VS2005 files, so I don't know if this is an issue 
of this specific generator or a more global one.

Best regards,
  Jens
___
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 2.8.6-rc3 ready for testing!

[Andrea Galeazzi]

David Cole ha scritto:

The CMake 2.8.6 release candidate stream continues! You can find the
source and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D

This email is also available on the Kitware blog at
http://www.kitware.com/blog/home/post/165

If you want to test this out and ask for a fix, do it soon, or hold your
peace till the next release! I expect we will finalize the 2.8.6 release
by mid-September.

This release candidate we do not have pre-built binaries for the
SunOS anymore. As mentioned on the CMake mailing list recently, our
Sun hardware has bitten the proverbial dust.

However, we are now providing two sets of installers for the Mac.
The "Darwin" versions are for Mac OSX 10.4 and later, and are "ppc;i386"
universal binaries. The "Darwin64" versions are for 10.6 and later,
and are "x86_64;i386" universal binaries.

Following is the list of changes in this release. Since we switched to
git, this list is now the 'git log' one line summary written by the
named CMake developers.

Please try this version of CMake on your projects and report any
issues to the list or the bug tracker.

Happy building!
-Dave


Changes in CMake 2.8.6-rc3 (since 2.8.6-rc2)

Alexey Ozeritsky (2):
  FindBLAS/LAPACK fixes
  FindBLAS/LAPACK fixes

Andreas Schneider (1):
  Modules: Add support for more java archives in add_jar().

Björn Ricks (4):
  Search for the installed python interpreter first
  Determine python version
  Update documentation of FindPythonInterp.cmake
  Use FIND_PACKAGE_HANDLE_STANDARD_ARGS second mode

Brad King (5):
  VS: Map per-source Fortran flags to IDE options
  VS: Map Fortran free- and fixed-format flags to IDE options
  Fortran: Add support for free- and fixed-form flags
  Xcode: Honor Fortran_FORMAT target and source file property
  Set CMAKE__COMPILER_ID for VS generators

David Cole (8):
  KWSys: Remove always-true dir_only parameter
  KWSys: Add symlinks to directories as files (#12284)
  FindPackageMessage: Eliminate new lines in cache entries
  FindPackageMessage: Eliminate new lines using REGEX REPLACE
  CMake: Add SaveCache at the end of successful Generate calls
  Suppress Qt warning for dashmacmini5 builds
  Suppress Qt warning for dashmacmini5 builds
  Tests: Look for "Illegal" or "SegFault" in the output

Eric NOULARD (2):
  CPack  fix #12366 components RPM packages have the same package name
  CPackRPM fix #12305, include directories in RPM package

Johan Björk (5):
  Xcode: No spaces in makefile target names (#12370)
  CMake: Write symlinks to directories as files in archives (#12284)
  CPack: Do not recurse through directory symlinks (#12284)
  Xcode: Do not emit the ZERO_CHECK target more than once
  Xcode: Honor -g0 to disable debugging (#12377)

Johannes Stallkamp (1):
  CTest: Fixed valgrind output parsing (#12260)

Matt McCormick (1):
  CMake: Remove documentation for -E build (#12446)

Stephen Kelly (2):
  Add some more unit tests.
  Don't put what some compilers consider junk at the end of the line.

Thomas Jarosch (3):
  CTest: Fix memory leaks on error
  Fix file() command descriptor leak on error
  ccmake: Fix off-by-one memory access error
___
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
  

Any news about when will it be finalized?

___
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] Setting RuntimeLibrary tag on Visual Studio 10

[Perry Ismangil]

On Tue, Sep 20, 2011 at 10:48, Yuri Timenkov  wrote:
> These flags should work. If you specify them, CMake automatically translates
> them into appropriate XML tags. At least 2.8.5 and 2.8.4 work well.
>

Thanks Yuri,

It does work!

I must have done something wrong earlier when setting the flags.

-- 
Perry Ismangil
___
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] CodeBlocks generator and source_group

[Tomasz Grobelny]

Is there any way to make cmake generate ‘’ element for Unit elements in CodeBlocks Project file (cbp)? I
would expect it to happen by using 'SOURCE_GROUP("Source Files" FILES
${SOURCES})' construct but it does not work for me (should it?).
-- 
Regards,
Tomasz Grobelny
___
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] SOLVED: Generated successfully NMake Makefile using CMake for Cross Compiling, but compiling with nmake fails

[Eric Noulard]

2011/9/20 Martin Kupke 
>
> Hi,
>
> short info for those of you who run into the same pitfall.
> I downloaded the free (free of charge) nmake tool version 1.50 from the 
> Microsoft website. The problem is this nmake tool which produces the problems 
> with blanks / spaces in folder- and filenames. Even parameters which contain 
> double quotes (") make problems in the Makefile.
> We have several installations of MS Visual Studio in different versions 
> (Visual Studio 2003, 2008, 2010) and now I tried the NMake from Visual Studio 
> 2003 which is file version 7.10.3077 and this works fine. Of course this 
> version is NOT free of charge, because it's part of the buyable package from 
> Microsoft.
>
> Just the short form: the nmake tool version 1.50 isn't able to use the 
> generated Makefile.

Thank you for the information.

May be Jom would be usable in your case
 https://qt.gitorious.org/qt-labs/jom

Pre-compiled JOM binaries may be found here:
ftp://ftp.qt.nokia.com/jom/

--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] SOLVED: Generated successfully NMake Makefile using CMake for Cross Compiling, but compiling with nmake fails

[Martin Kupke]

  
  
Hi,

short info for those of you who run into the same pitfall.
I downloaded the free (free of charge) nmake tool version 1.50 from
the Microsoft website. The problem is this nmake tool which produces
the problems with blanks / spaces in folder- and filenames. Even
parameters which contain double quotes (") make problems in the
Makefile.
We have several installations of MS Visual Studio in different
versions (Visual Studio 2003, 2008, 2010) and now I tried the NMake
from Visual Studio 2003 which is file version 7.10.3077 and this
works fine. Of course this version is NOT free of charge, because
it's part of the buyable package from Microsoft.

Just the short form: the nmake tool version 1.50 isn't able to use
the generated Makefile.

Br,
Martin...

On 20.09.11 11:00, Martin Kupke wrote:

  Hi,

after many helpful hints from other users now I was able to create a 
NMake Makefile using CMake.
I'm working in a Windows XP environment in a cmd.exe command line 
interface (shell). The CMake tool created the typical Makefile including 
the subfolders etc. in my output folder, without any errors or warnings. 
To compile my simple test project (in moment it contains only a single 
source standard C file), I call nmake.exe in my output path in the 
console. This is the same as calling nmake.exe with the parameter -f 
Makefile.

The output of the nmake build process is:
 snip 
D:\novero\Discovery\impl\target\CarIF_Appl\output\Debug>nmake -f Makefile

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.
 snap 

I assume that there is a problem with the filename / foldername, because 
of the line:
'C:\Program' is not recognized as an internal or external command...
A search over the output files from CMake including the generated 
Makefile itself shows that all references in variables are set with 
double quote (") e.g. "C:\Program Files\CMake 2.8\bin\cmake.exe".

Many thanks for your helpful comments in advance.

Br,
Martin...



___
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



-- 
  
  
  


  
  martin
kupke
   can diagnostics
  engineer | senior software developer
  
  m: +49.151.5511.3632 | e: martin.ku...@novero.com
  skype: 
martin.kupke_novero 
| w: www.novero.com
  



meesmannstr.103 | 44807 Bochum | germany

   
  novero gmbh | parsevalstr.  7 a | 40468 düsseldorf | germany |
  amtsgericht düsseldorf | hrb 58283 |
  umsatzsteueridentifikationsnummer: de 814973142 |
  geschäftsführender gesellschafter: razvan olosu 
  
   

  

  

___
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] Setting RuntimeLibrary tag on Visual Studio 10

[Yuri Timenkov]

These flags should work. If you specify them, CMake automatically translates
them into appropriate XML tags. At least 2.8.5 and 2.8.4 work well.

On Tue, Sep 20, 2011 at 1:16 PM, Perry Ismangil  wrote:

> Hi,
>
> I've read
>
>
> http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
>
> which seems to do what I want to which is have 4 configurations one
> for each: MT, MTd, MD, MDd.
>
> However using flags doesn't seem to work as it is this tag that is
> important:
>
> MultiThreadedDebug
>
> Is there anyway to control what is put on the RuntimeLibrary for
> Visual Studio 10 generation?
>
> Thanks.
>
> --
> Perry Ismangil
> ___
> 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
>
___
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] not found library with package configuration files and changed CMAKE_INSTALL_PREFIX

[Alexander Dahl]

Hello there, 

after using FindFOO.cmake scripts for our own projects for a long time
I'm trying to migrate this to the "real" CMake approach of package
configuration files. Therefor I read chapter 5.7 of the book »Mastering
CMake« and two HowTos [1] [2] on the web merging all of these in some
files. I have own shared C library "foo" and one C command line tool
"bar" and try to build this on Ubuntu Lucid 10.04 with a self compiled
cmake 2.8.4.

This works fine as long as I don't change CMAKE_INSTALL_PREFIX (with
`make edit_cache` or earlier when calling `cmake
-DCMAKE_INSTALL_PREFIX=/some/path /path/to/src`) and it is /usr/local –
however when changing this to /home/adahl/usr (or any other non standard
path) linking the library fails although the include files are still
found (FOO_DIR is correctly set to /home/adahl/usr/lib/cmake/foo).

I'll show my CMakeList.txt files and the package configuration stuff,
maybe someone could have a look and point me to my errors.

In project "foo" which builds a shared C library:

CMakeLists.txt:

  4 project(foo)
  5
  6 cmake_minimum_required(VERSION 2.8)
  7
  8 set(PACKAGE_MAJOR_VERSION "0")
  9 set(PACKAGE_MINOR_VERSION "1")
 10 set(PACKAGE_BUILD_VERSION "0")
 11 set(PACKAGE_VERSION
"${PACKAGE_MAJOR_VERSION}.${PACKAGE_MINOR_VERSION}.${PACKAGE_BUILD_VERSION}"
   )
 12
 13 add_subdirectory("inc")
 14 add_subdirectory("src")
 15
 16 configure_file(
 17 ${CMAKE_CURRENT_SOURCE_DIR}/foo-config.cmake.in
 18 ${CMAKE_CURRENT_BINARY_DIR}/foo-config.cmake @ONLY
 19 )
 20 configure_file(
 21 ${CMAKE_CURRENT_SOURCE_DIR}/foo-config-version.cmake.in
 22 ${CMAKE_CURRENT_BINARY_DIR}/foo-config-version.cmake @ONLY
 23 )
 24 install(FILES
 25 ${CMAKE_CURRENT_BINARY_DIR}/foo-config.cmake
 26 ${CMAKE_CURRENT_BINARY_DIR}/foo-config-version.cmake
 27 DESTINATION "lib/cmake/${PROJECT_NAME}"
 28 )

foo-config.cmake.in:

  4 get_filename_component(_dir "${CMAKE_CURRENT_LIST_FILE}" PATH)
  5 get_filename_component(_prefix "${_dir}/../../.." ABSOLUTE)
  6 include("${_dir}/@PROJECT_NAME@-targets.cmake")
  7 set(FOO_INCLUDE_DIRS "${_prefix}/include/@PROJECT_NAME@")

foo-config-version.cmake.in:

  4 set(PACKAGE_VERSION "@PACKAGE_VERSION@")
  5
  6 if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}")
  7 set(PACKAGE_VERSION_COMPATIBLE FALSE)
  8 else()
  9 set(PACKAGE_VERSION_COMPATIBLE TRUE)
 10 if ("${PACKAGE_VERSION}" VERSION_EQUAL
"${PACKAGE_FIND_VERSION}")
 11 set(PACKAGE_VERSION_EXACT TRUE)
 12 endif()
 13 endif()

inc/CMakeLists.txt:

  4 install(FILES
  5 foo.h
  6 DESTINATION "include/${PROJECT_NAME}"
  7 )

src/CMakeLists.txt:

  4 set(FOO_SRC
  5 foo.c
  6 )
  7
  8 include_directories(
  9 "${PROJECT_SOURCE_DIR}/inc"
 10 )
 11
 12 add_library(${PROJECT_NAME}-shared SHARED ${FOO_SRC})
 13 set_target_properties(${PROJECT_NAME}-shared PROPERTIES
 14 OUTPUT_NAME ${PROJECT_NAME}
 15 SOVERSION   ${PACKAGE_MAJOR_VERSION}
 16 VERSION ${PACKAGE_VERSION}
 17 )
 18 install(TARGETS ${PROJECT_NAME}-shared DESTINATION "lib" EXPORT
${PROJECT_NAME}-targets)
 19 install(EXPORT ${PROJECT_NAME}-targets DESTINATION
"lib/cmake/${PROJECT_NAME}")

This allows successful build of the library with all files installed
where they should be, at least binaries and header files. The package
configuration files are installed like this:

% ls -l /home/adahl/usr/lib/cmake/foo
insgesamt 16
-rw-r--r-- 1 adahl adahl  248 2011-09-20 11:09 foo-config.cmake
-rw-r--r-- 1 adahl adahl  334 2011-09-20 11:09 foo-config-version.cmake
-rw-r--r-- 1 adahl adahl  924 2011-09-20 11:09 foo-targets.cmake
-rw-r--r-- 1 adahl adahl 1041 2011-09-20 11:09
foo-targets-noconfig.cmake

Now first I build this library like this:

~/Work/build/libfoo % cmake -DCMAKE_INSTALL_PREFIX=/home/adahl/usr
../../src/libfoo
~/Work/build/libfoo % make
~/Work/build/libfoo % make install

No problem so far, but when building the cli tool »bar« like this:

~/Work/build/bar % cmake -DCMAKE_INSTALL_PREFIX=/home/adahl/usr
../../src/bar
~/Work/build/bar % make

This fails like this:

Linking C executable bar
/usr/bin/ld: cannot find -lfoo
collect2: ld returned 1 exit status

(Note: when not changing CMAKE_INSTALL_PATH this works.)

The cmake files for "bar" look like this:

CMakeLists.txt:

  4 project(m16c-progflash)
  5
  6 cmake_minimum_required(VERSION 2.8)
  7
  8 set(PACKAGE_MAJOR_VERSION "0")
  9 set(PACKAGE_MINOR_VERSION "1")
 10 set(PACKAGE_BUILD_VERSION "0")
 11 set(PACKAGE_VERSION
"${PACKAGE_MAJOR_VERSION}.${PACKAGE_MINOR_VERSION}.${PACKAGE_BUILD_VERSION}"
   )
 12
 16 find_package(FOO 0.1 REQUIRED)
 17
 18 add_subdirectory("src")

src/CMakeLists.txt:

 11 set(BAR_SRC
 12 bar.c
 13 )
 14
 15 include_directories(
 16 ${CMAKE_CURRENT_BINARY_DIR}
 17 ${FOO_INCLUDE_DIRS}
 18 )
 19 add_executable(${PROJECT_NAME} ${BAR_SRC})
 20
 21 target_link_libraries(${PROJECT_NAME} foo)
 22
 23 install(TARGETS ${PROJECT_NAME} DESTINATION bin)

With the former find scri

[CMake] Setting RuntimeLibrary tag on Visual Studio 10

[Perry Ismangil]

Hi,

I've read

http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F

which seems to do what I want to which is have 4 configurations one
for each: MT, MTd, MD, MDd.

However using flags doesn't seem to work as it is this tag that is important:

MultiThreadedDebug

Is there anyway to control what is put on the RuntimeLibrary for
Visual Studio 10 generation?

Thanks.

-- 
Perry Ismangil
___
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] Generated successfully NMake Makefile using CMake for Cross Compiling, but compiling with nmake fails

[Martin Kupke]

Hi,

after many helpful hints from other users now I was able to create a 
NMake Makefile using CMake.
I'm working in a Windows XP environment in a cmd.exe command line 
interface (shell). The CMake tool created the typical Makefile including 
the subfolders etc. in my output folder, without any errors or warnings. 
To compile my simple test project (in moment it contains only a single 
source standard C file), I call nmake.exe in my output path in the 
console. This is the same as calling nmake.exe with the parameter -f 
Makefile.


The output of the nmake build process is:
 snip 
D:\novero\Discovery\impl\target\CarIF_Appl\output\Debug>nmake -f Makefile

Microsoft (R) Program Maintenance Utility   Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.
 snap 

I assume that there is a problem with the filename / foldername, because 
of the line:

'C:\Program' is not recognized as an internal or external command...
A search over the output files from CMake including the generated 
Makefile itself shows that all references in variables are set with 
double quote (") e.g. "C:\Program Files\CMake 2.8\bin\cmake.exe".


Many thanks for your helpful comments in advance.

Br,
Martin...



___
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] Cross compiling in Win32 environment doesn't work

[Martin Kupke]

Hi Alex,

sorry for sending mails in HTML format (hopefully the mail client is now 
configured correctly).

You'll find my answers to your comments below.

On 20.09.11 05:29, Alexander Neundorf wrote:

Hi,

can you please adjust your mail client so it doesn't send HTML mails ?

On Monday, September 19, 2011 04:57:32 PM Martin Kupke wrote:

  That's a hint, I changed my toolchain file "toolchain_ppc.cmake" to the
following: INCLUDE(CMakeForceCompiler)
  set(CMAKE_SYSTEM_NAME "Discovery")

  if(CMAKE_CROSSCOMPILING)
  message("Cross Compiling")
  endif(CMAKE_CROSSCOMPILING)

  # which compilers to use for C and C++
  set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
  set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
  set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")

  Then I created a folder with the name Platform containing a file with
CMAKE_SYSTEM_NAME which is Discovery ->  at this point I had already
problems, because CMake doesn't use as described the filename with .cmake
extension. The filename in the Platform folder has to have the name from
CMAKE_SYSTEM_NAME without the extension .cmake (even the documentation
says something different). I checked this by adding the output of a
message("SYSTEM_NAME=Discovery").

The filename must be Discovery.cmake in your case.
Did you say this didn't work ?
This file must be either in the cmake Modules/Platfom/ directory, or in a
subdirectory Platform/ of a directory which is in CMAKE_MODULE_PATH.
Yes, I created the folder Platform in my CMAKE_MODULE_PATH and within 
this folder the file Discovery.cmake.
This doesn't work! I checked it using the message tag to output a string 
on the console.
After renaming the Discovery.cmake to only basename Discovery without 
the extension .cmake, the file was included.
So, the extension .cmake isn't correct...even it is described in the 
documentation.
The output of the CMake tool, if using the CMAKE_SYSTEM_NAME set to 
"Discovery":

### snip ###
D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake 
Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..

Cross Compiling
-- The C compiler identification is unknown
-- Check for working C compiler: c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
System is unknown to cmake, create:
Platform/Discovery to use this system, please send your config file to 
cm...@www.cmake.org so it can be added to cmake
-- Check for working C compiler: 
c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe --works

-- Detecting C compiler ABI info
System is unknown to cmake, create:
Platform/Discovery to use this system, please send your config file to 
cm...@www.cmake.org so it can be added to cmake

-- Detecting C compiler ABI info - done
C compiler: c:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe
C flags:  -tPPCVLEEN:simple
Mein CMakeLists.txt File
-- Configuring done
-- Generating done
-- Build files have been written to: 
D:/novero/Discovery/impl/target/CarIF_Appl/output

### snap ###
It seems to work, even there are some hints that CMake doesn't know the 
system Discovery.

I fixed the problem by using the CMAKE_SYSTEM_NAME set to "Generic".
With "Generic" I need a configuration file in the Platform folder named 
to "Generic-dcc" with the compile flags.

The name in the Platform folder again is used without the extension .cmake!
"Generic" needs to be added with "-dcc" because of the Base name of the 
dcc.exe compiler.
This now works and creates the Makefile in the output folder as wanted, 
without any errors / warnings ...



  The Platform/Discovery file contains the lines:
  message("SYSTEM_NAME=Discovery")
  set(CMAKE_FORCE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
  set(CMAKE_C_COMPILER "C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe")
  set(CMAKE_C_FLAGS "-tPPCVLEEN:simple")
  set(CMAKE_FORCE_C_FLAGS "-tPPCVLEEN:simple")
  set(CMAKE_FORCE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_COMPILER
"C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe") set(CMAKE_CXX_FLAGS
"-tPPCVLEEN:simple")
  set(CMAKE_MAKE_PROGRAM "D:/novero/Discovery/impl/win32/nmake/nmake.exe")

That last line should not be necessary.
I thought this would help to point to the nmake tool in the Makefile, in 
case it is not in the search path of the system.

  Then I call from the command line the CMake tool with the parameters:
  D:\novero\Discovery\impl\target\CarIF_Appl\output>cmake -G "NMake
Makefiles" -D CMAKE_TOOLCHAIN_FILE="..\toolchain_ppc.cmake" ..

  The following output will be produced:
  * snip output *
  Cross Compiling
  -- The C compiler identification is unknown
  -- The CXX compiler identification is unknown
  SYSTEM_NAME=Discovery
  SYSTEM_NAME=Discovery
  -- Check for working C compiler:
C:/WindRiver/diab/5.9.0.0/WIN32/bin/dcc.exe System is unknown to cmake,
create:
  Platform/Discovery to use this system,