Re: [CMake] Why is Ninja generator disabled by default?

[Bill Hoffman]

Could be a change in ninja.  Our machine updates ninja each build.

- sent from my open source android phone.
On May 22, 2012 6:55 PM, "Claus Klein"  wrote:

> But it works for each variant:
>
> claus-kleins-macbook-pro:My Tests clausklein$ mkdir ninja
> claus-kleins-macbook-pro:My Tests clausklein$ cd ninja/
> claus-kleins-macbook-pro:ninja clausklein$ pwd
> /Users/clausklein/Downloads/**cmake/My Tests/ninja
> claus-kleins-macbook-pro:ninja clausklein$ "/usr/local/CMake
> 2.8-8.app/Contents/bin/cmake" -G Ninja -DMAKE_SUPPORTS_SPACES=0 ../../Tests/
> **CompileCommandOutput/
> -- The CXX compiler identification is GNU 4.7.0
> -- Checking whether CXX compiler has -isysroot
> -- Checking whether CXX compiler has -isysroot - yes
> -- Checking whether CXX compiler supports OSX deployment target flag
> -- Checking whether CXX compiler supports OSX deployment target flag - yes
> -- Check for working CXX compiler using: Ninja
> -- Check for working CXX compiler using: Ninja -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/clausklein/Downloads/**cmake/My
> Tests/ninja
>
> claus-kleins-macbook-pro:ninja clausklein$ ninja -d explain
> ninja explain: output CMakeFiles/test2.dir/relative.**cxx.o doesn't exist
> ninja explain: CMakeFiles/test2.dir/relative.**cxx.o is dirty
> ninja explain: output CMakeFiles/test1.dir/file_**with_spaces.cxx.o
> doesn't exist
> ninja explain: CMakeFiles/test1.dir/file_**with_spaces.cxx.o is dirty
> ninja explain: output 
> CMakeFiles/**CompileCommandOutput.dir/**compile_command_output.cxx.o
> doesn't exist
> ninja explain: 
> CMakeFiles/**CompileCommandOutput.dir/**compile_command_output.cxx.o
> is dirty
> ninja explain: libtest1.a is dirty
> ninja explain: libtest2.dylib is dirty
> ninja explain: CompileCommandOutput is dirty
> ninja explain: libtest1.a is dirty
> ninja explain: libtest2.dylib is dirty
> [6/6] Linking CXX executable CompileCommandOutput
> claus-kleins-macbook-pro:ninja clausklein$ ls -lrta
> total 72
> drwxr-xr-x  4 clausklein staff   136 May 23 00:49 ..
> -rw-r--r--  1 clausklein staff  2989 May 23 00:50 rules.ninja
> -rw-r--r--  1 clausklein staff  1492 May 23 00:50 cmake_install.cmake
> -rw-r--r--  1 clausklein staff  9248 May 23 00:50 build.ninja
> -rw-r--r--  1 clausklein staff 10666 May 23 00:50 CMakeCache.txt
> -rwxr-xr-x  1 clausklein staff 12432 May 23 00:50 libtest2.dylib
> -rw-r--r--  1 clausklein staff   672 May 23 00:50 libtest1.a
> -rwxr-xr-x  1 clausklein staff 12652 May 23 00:50 CompileCommandOutput
> drwxr-xr-x 13 clausklein staff   442 May 23 00:50 CMakeFiles
> -rw-r--r--  1 clausklein staff  1934 May 23 00:50 .ninja_log
> drwxr-xr-x 11 clausklein staff   374 May 23 00:50 .
> claus-kleins-macbook-pro:ninja clausklein$
>
> claus-kleins-macbook-pro:ninja clausklein$ ninja clean
> [1/1] Cleaning all built files...
> Cleaning... 9 files.
> claus-kleins-macbook-pro:ninja clausklein$ ninja rebuild_cache
> [1/1] Running CMake to regenerate build system...
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/clausklein/Downloads/**cmake/My
> Tests/ninja
> claus-kleins-macbook-pro:ninja clausklein$ ninja
> [6/6] Linking CXX executable CompileCommandOutput
> claus-kleins-macbook-pro:ninja clausklein$
>
> space in source; space in working dir, ...
>
> Claus
>
> On 23.05.2012, at 00:42, Richard Wackerbarth wrote:
>
>  Yes, you changed the test configuration and that configuration will work.
>> However, for other generators, you do not need to add the
>> -DMAKE_SUPPORTS_SPACES
>>
>> Richard
>>
>> On May 22, 2012, at 5:18 PM, Claus Klein 
>> wrote:
>>
>>> claus-kleins-macbook-pro:**CompileCommandOutput clausklein$
>>> "/usr/local/CMake 2.8-8.app/Contents/bin/cmake" -G Ninja
>>> -DMAKE_SUPPORTS_SPACES=1
>>>
>>
> --
>
> 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

Re: [CMake] Why is Ninja generator disabled by default?

[Claus Klein]

But it works for each variant:

claus-kleins-macbook-pro:My Tests clausklein$ mkdir ninja
claus-kleins-macbook-pro:My Tests clausklein$ cd ninja/
claus-kleins-macbook-pro:ninja clausklein$ pwd
/Users/clausklein/Downloads/cmake/My Tests/ninja
claus-kleins-macbook-pro:ninja clausklein$ "/usr/local/CMake 2.8-8.app/ 
Contents/bin/cmake" -G Ninja -DMAKE_SUPPORTS_SPACES=0 ../../Tests/ 
CompileCommandOutput/

-- The CXX compiler identification is GNU 4.7.0
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag -  
yes

-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/clausklein/Downloads/cmake/ 
My Tests/ninja


claus-kleins-macbook-pro:ninja clausklein$ ninja -d explain
ninja explain: output CMakeFiles/test2.dir/relative.cxx.o doesn't exist
ninja explain: CMakeFiles/test2.dir/relative.cxx.o is dirty
ninja explain: output CMakeFiles/test1.dir/file_with_spaces.cxx.o  
doesn't exist

ninja explain: CMakeFiles/test1.dir/file_with_spaces.cxx.o is dirty
ninja explain: output CMakeFiles/CompileCommandOutput.dir/ 
compile_command_output.cxx.o doesn't exist
ninja explain: CMakeFiles/CompileCommandOutput.dir/ 
compile_command_output.cxx.o is dirty

ninja explain: libtest1.a is dirty
ninja explain: libtest2.dylib is dirty
ninja explain: CompileCommandOutput is dirty
ninja explain: libtest1.a is dirty
ninja explain: libtest2.dylib is dirty
[6/6] Linking CXX executable CompileCommandOutput
claus-kleins-macbook-pro:ninja clausklein$ ls -lrta
total 72
drwxr-xr-x  4 clausklein staff   136 May 23 00:49 ..
-rw-r--r--  1 clausklein staff  2989 May 23 00:50 rules.ninja
-rw-r--r--  1 clausklein staff  1492 May 23 00:50 cmake_install.cmake
-rw-r--r--  1 clausklein staff  9248 May 23 00:50 build.ninja
-rw-r--r--  1 clausklein staff 10666 May 23 00:50 CMakeCache.txt
-rwxr-xr-x  1 clausklein staff 12432 May 23 00:50 libtest2.dylib
-rw-r--r--  1 clausklein staff   672 May 23 00:50 libtest1.a
-rwxr-xr-x  1 clausklein staff 12652 May 23 00:50 CompileCommandOutput
drwxr-xr-x 13 clausklein staff   442 May 23 00:50 CMakeFiles
-rw-r--r--  1 clausklein staff  1934 May 23 00:50 .ninja_log
drwxr-xr-x 11 clausklein staff   374 May 23 00:50 .
claus-kleins-macbook-pro:ninja clausklein$

claus-kleins-macbook-pro:ninja clausklein$ ninja clean
[1/1] Cleaning all built files...
Cleaning... 9 files.
claus-kleins-macbook-pro:ninja clausklein$ ninja rebuild_cache
[1/1] Running CMake to regenerate build system...
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/clausklein/Downloads/cmake/ 
My Tests/ninja

claus-kleins-macbook-pro:ninja clausklein$ ninja
[6/6] Linking CXX executable CompileCommandOutput
claus-kleins-macbook-pro:ninja clausklein$

space in source; space in working dir, ...

Claus

On 23.05.2012, at 00:42, Richard Wackerbarth wrote:

Yes, you changed the test configuration and that configuration will  
work. However, for other generators, you do not need to add the - 
DMAKE_SUPPORTS_SPACES


Richard

On May 22, 2012, at 5:18 PM, Claus Klein   
wrote:
claus-kleins-macbook-pro:CompileCommandOutput clausklein$ "/usr/ 
local/CMake 2.8-8.app/Contents/bin/cmake" -G Ninja - 
DMAKE_SUPPORTS_SPACES=1


--

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] Why is Ninja generator disabled by default?

[Richard Wackerbarth]

Yes, you changed the test configuration and that configuration will work. 
However, for other generators, you do not need to add the -DMAKE_SUPPORTS_SPACES

Richard

On May 22, 2012, at 5:18 PM, Claus Klein  wrote:
> claus-kleins-macbook-pro:CompileCommandOutput clausklein$ "/usr/local/CMake 
> 2.8-8.app/Contents/bin/cmake" -G Ninja -DMAKE_SUPPORTS_SPACES=1 
--

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] Why is Ninja generator disabled by default?

[Claus Klein]

it works on my macbook:

"/usr/local/CMake 2.8-8.app/Contents/bin/cmake" --version
cmake version 2.8.8.20120520-g4742e

claus-kleins-macbook-pro:CompileCommandOutput clausklein$ "/usr/local/ 
CMake 2.8-8.app/Contents/bin/cmake" -G Ninja -DMAKE_SUPPORTS_SPACES=1

-- The CXX compiler identification is GNU 4.7.0
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag -  
yes

-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/clausklein/Downloads/cmake/ 
Tests/CompileCommandOutput


claus-kleins-macbook-pro:CompileCommandOutput clausklein$ ninja -d  
explain
ninja explain: output CMakeFiles/test1.dir/file_with_spaces.cxx.o  
doesn't exist

ninja explain: CMakeFiles/test1.dir/file_with_spaces.cxx.o is dirty
ninja explain: output CMakeFiles/test2.dir/relative.cxx.o doesn't exist
ninja explain: CMakeFiles/test2.dir/relative.cxx.o is dirty
ninja explain: output CMakeFiles/CompileCommandOutput.dir/ 
compile_command_output.cxx.o doesn't exist
ninja explain: CMakeFiles/CompileCommandOutput.dir/ 
compile_command_output.cxx.o is dirty

ninja explain: libtest1.a is dirty
ninja explain: libtest2.dylib is dirty
ninja explain: CompileCommandOutput is dirty
ninja explain: libtest1.a is dirty
ninja explain: libtest2.dylib is dirty
[6/6] Linking CXX executable CompileCommandOutput
claus-kleins-macbook-pro:CompileCommandOutput clausklein$

claus-kleins-macbook-pro:CompileCommandOutput clausklein$ touch file\  
with\ spaces.cxx
claus-kleins-macbook-pro:CompileCommandOutput clausklein$ ninja -d  
explain
ninja explain: output CMakeFiles/test1.dir/file_with_spaces.cxx.o  
older than most recent input file with spaces.cxx (1337723824000  
vs 1337723927000)

ninja explain: CMakeFiles/test1.dir/file_with_spaces.cxx.o is dirty
ninja explain: libtest1.a is dirty
ninja explain: CompileCommandOutput is dirty
ninja explain: libtest1.a is dirty
[3/3] Linking CXX executable CompileCommandOutput
claus-kleins-macbook-pro:CompileCommandOutput clausklein$


On 22.05.2012, at 13:35, Richard Wackerbarth wrote:

One of the differences that shows up in the dashboard is that there  
is a compile test which passes with normal Unix file paths, but  
fails when there is a space in one of the directory names. Perhaps  
we need to add an explicit test for everyone, ninja or otherwise, to  
test that compiles work with spaces in the path. I have a feeling  
that we may find additional failures.


On May 22, 2012, at 6:02 AM, David Cole wrote:


Please take a look at the CMake dashboard:

  http://open.cdash.org/index.php?project=CMake

I will allow the ninja generator to be enabled by default after  
interested parties fix all the failing tests in the "Nightly  
Expected" section related to the ninja generator submissions.


Honestly, I was opposed to the ninja generator being merged to  
'master' and enabled at all because of the failing tests on our  
dashboard. Luckily for all you ninja fans out there, I do not have  
dictator powers. ;-)



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


--

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] Undefine a project()

[Robert Dailey]

Thanks for the information!

On Tue, May 22, 2012 at 3:27 PM, David Cole  wrote:

> It is customary, but not enforced, to have only one project command in a
> CMakeLists.txt file.
>
> The project command maps to generated *.sln files for the Visual Studio
> generators.
>
> All targets defined after the project command in the same CMakeLists.txt
> file, or any included by virtue of add_subdirectory, will appear in the
> *.sln file that corresponds to that project command.
>
> To prevent this, simply organize things differently.
>
> There's no way with existing CMake to undefine a project or target.
>
>
> HTH,
> David
>
>
> On Tue, May 22, 2012 at 2:49 PM, Robert Dailey 
> wrote:
>
>> Hi,
>>
>> I was wondering if there is a way to undefined a project(). I want to do
>> this to prevent projects from being included in a solution when I generate
>> for Visual Studio. Example:
>>
>> project( A )
>> add_executable( A a.cpp )
>> project( B )
>> add_executable( B b.cpp )
>> add_executable( C c.cpp )
>>
>> I don't want B to be in A's solution when I open A.sln. I'm assuming this
>> is the behavior, unless project(B) call cancels out project(A)?
>>
>> Also, I don't want project C to appear in either A or B solutions.
>>
>> The reason why I'm doing this is because I have setup my CMake scripts to
>> allow a solution file to be generated for executables (so I can open each
>> executable solution in different instances of visual studio, with ONLY that
>> executable + dependency projects in it). However, since sometimes multiple
>> executable projects can be defined in the same directory, or other
>> libraries that aren't a dependency of that executable, I do not want those
>> to be included in the project().
>>
>> --
>>
>> 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

Re: [CMake] CPack: Installing applications in separate folders (NSIS)

[David Cole]

You're welcome.

Be careful with that technique, though.

If somebody configures your project with CMAKE_INSTALL_PREFIX set to
C:/Put/Stuff/Here, they'll end up with your main install tree underneath
that, and then all your custom dir files in "C:/Put/Stuff/CustomDir".


On Tue, May 22, 2012 at 3:31 PM,  wrote:

> I got it to work.
>
> Under windows/NSIS I set the destination to "../CustomDir" instead of
> $CustomDir.
> With this and a custom nsis script which knows the location it is possible
> to run CPack.
>
> In the NSIS script I've the following
> Var $CustomDir="@CPACK_TEMPORARY_DIRECTORY@\..\CustomDir"
>
> After this I can install files from this directory too.
>
> The directory content after the preinstall:
> .../_CPack_Packages/win32/NSIS/myproject.1.0.0.1/
> .../_CPack_Packages/win32/NSIS/CustomDir/
> .../_CPack_Packages/win32/NSIS/project.nsi
> .
> .
> .
>
> @Eric, @David: Thank you very much
>
> Best Regards
>
>
> Am 22.05.2012 um 00:38 schrieb Eric Noulard :
>
> > 2012/5/21 David Cole :
> >> On Mon, May 21, 2012 at 2:05 PM,  wrote:
> >>>
> >>> But what about other systems like linux. If I have an executable and
> >>> shared libraries for example.
> >>> Then it is possible to install it under /opt/myproject, but it is not
> >>> possible to install the executable under /usr/bin and the shared
> libraries
> >>> under /usr/lib? Or did I misunderstood something?
> >>
> >>
> >> But you don't build an NSIS installer based on those.
> >
> > And installing lib in /usr/lib and exe in /usr/bin IS possible
> > because the 2 path shares the /usr prefix.
> >
> > On Linux if you build an RPM or DEB package which contains various
> > prefix (/usr /opt etc..) you either get a non relocatable package
> > or decide that some files are "special" like config files.
> >
> > but David is right this does not work with NSIS.
> >
> >>> Sorry, for simple installers the default NSIS template is great, but
> for
> >>> customized ones it seems to be very difficult, isn't it?
> >
> > As difficult as it is with NSIS alone :-]
> >
> >> Yes, you're correct. It takes some effort if you are not installing
> >> everything underneath the directory that the end user chooses for your
> final
> >> location.
> >>
> >> It's quite good for "simple installers" and "component-based
> installers" --
> >> beyond that, and especially putting things outside the location chosen
> by
> >> the end user ... you're on your own.
> >
> > If you do have 2 separate unrelated installation prefixes
> > may be you can just build 2 NSIS installers
> > (which contains only one prefix)
> > using CPack twice out of 2 differents configurations of the same project
> >
> > Or craft your own project.nsi file.
> >
> > --
> > Erk
> > Le gouvernement représentatif n'est pas la démocratie --
> > http://www.le-message.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] Undefine a project()

[David Cole]

It is customary, but not enforced, to have only one project command in a
CMakeLists.txt file.

The project command maps to generated *.sln files for the Visual Studio
generators.

All targets defined after the project command in the same CMakeLists.txt
file, or any included by virtue of add_subdirectory, will appear in the
*.sln file that corresponds to that project command.

To prevent this, simply organize things differently.

There's no way with existing CMake to undefine a project or target.


HTH,
David


On Tue, May 22, 2012 at 2:49 PM, Robert Dailey wrote:

> Hi,
>
> I was wondering if there is a way to undefined a project(). I want to do
> this to prevent projects from being included in a solution when I generate
> for Visual Studio. Example:
>
> project( A )
> add_executable( A a.cpp )
> project( B )
> add_executable( B b.cpp )
> add_executable( C c.cpp )
>
> I don't want B to be in A's solution when I open A.sln. I'm assuming this
> is the behavior, unless project(B) call cancels out project(A)?
>
> Also, I don't want project C to appear in either A or B solutions.
>
> The reason why I'm doing this is because I have setup my CMake scripts to
> allow a solution file to be generated for executables (so I can open each
> executable solution in different instances of visual studio, with ONLY that
> executable + dependency projects in it). However, since sometimes multiple
> executable projects can be defined in the same directory, or other
> libraries that aren't a dependency of that executable, I do not want those
> to be included in the project().
>
> --
>
> 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

Re: [CMake] Volunteering to become maintainer of FindLibLZMA.cmake

[Alexander Neundorf]

On Monday 14 May 2012, Mario Bensi wrote:
> Hi,
> 
> The last file with all change requested is correct for you ?
> 
> Do you think it's possible to integrate it in cmake ?

I'd say it looks good now.

Did you follow these steps already ?
http://www.cmake.org/Wiki/CMake/Git/Account#Git

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] fixup_bundle() doesn't like libglut.3.dylib

[Joe Ping-Lin Hsiao]

Turns out that ImageMagick is only used by test routines in my
program. I just comment out those routines in CMakeLists.txt and the
main program builds and works fine. I don't have to worry about OpenCL
anymore.

I think this is ImageMagick's fault. If I need this library in the
future, I'll probably need to build the program separately in 10.7 in
order to run it in 10.7.
And thanks David, your posts have been very helpful.

Best,
Joe


On Tue, May 22, 2012 at 12:06 PM, Michael Jackson
 wrote:
> It seems that this library is ONLY installed with Xcode which leads me to 
> believe that libclparser.dylib should ONLY be used during development and is 
> NOT a deployable library. Yes there are all sorts of ideas about copying it 
> from Snow Leopard but there are both technical and legal issues surrounding 
> someone other than Apple distributing that library.
> ___
> Mike Jackson                    Principal Software Engineer
> BlueQuartz Software                            Dayton, Ohio
> mike.jack...@bluequartz.net              www.bluequartz.net
>
> On May 22, 2012, at 11:54 AM, Joe Ping-Lin Hsiao wrote:
>
>> My Lion has OpenCL framework too. But if you go down the path, there
>> is no 'libclparser.dylib' in
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/,
>> while it exits in Snow Leopard.
>>
>> And by googling ImageMagick and libclparser.dylib, I found people
>> having this issue as well. The solution I see so far is to copy the
>> .dylib into Lion.
>>
>> -Joe
>>
>> On Tue, May 22, 2012 at 11:35 AM, Michael Jackson
>>  wrote:
>>> You have a bad install of Lion (OS X 10.7.x). I just checked 3 different 
>>> Lion machines and ALL have OpenCL.framework installed. So I would suspect 
>>> your Lion Machine. Lion uses OpenCL for lots of system level calls so a 
>>> Lion Install without OpenCL is just plain Broken.
>>>
>>> ___
>>> Mike Jackson                    Principal Software Engineer
>>> BlueQuartz Software                            Dayton, Ohio
>>> mike.jack...@bluequartz.net              www.bluequartz.net
>>>
>>> On May 22, 2012, at 11:18 AM, Joe Ping-Lin Hsiao wrote:
>>>
 Sorry I forgot to mention what the framework is. I believe the OpenCL
 framework is from MacOS since I checked two Snow Leopard machines and
 both have the framework.

 I am building my program in Snow Leopard. The program uses a library
 called 'ImageMagick', which uses the OpenCL framework. In Snow
 Leopard, I don't have to do anything special to OpenCL. It is just
 like any other system library, and my bundle and installer work fine
 in Snow Leopard.

 The problem is the OpenCL framework is not included in Lion (MacOS
 10.7). I don't know why Apple changed that. So my program would crash
 if running in Lion.
 My work around was to copy 'libclparser.dylib' into my bundle and
 manually change it's install_name, and also the one used by
 ImageMagick. Luckily it works. Now I am trying to make CMake to do it.


 On Tue, May 22, 2012 at 10:48 AM, David Cole  
 wrote:
> My previous email was your first hint that this might not be a good idea.
>
> This error message is the second hint that this might not be a good idea.
>
> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
> fixup_bundle. That will recursively copy the framework into the bundle
> rather than selectively copying just the framework library and its
> "Resources" folder.
>
> I am very hesitant to recommend copying a "/System" framework into a 
> bundle
> without knowing more details about where that framework came from.
>
>
> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
> wrote:
>>
>> After setting the framework type to 'other', the framework structure
>> is copied into my bundle, including the file OpenCL, but missing
>> libclparser.dylib.
>>
>> And I got the following errors:
>>
>> CPack: Create package using DragNDrop
>> CPack: Install projects
>> CPack: - Run preinstall target for: CISMM_VIDEO
>> CPack: - Install project: CISMM_VIDEO
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>                             // print out by me
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>                             // print out by me
>>  exe_dotapp_dir/='/Users/phsi

Re: [CMake] CPack: Installing applications in separate folders (NSIS)

[norulez]

I got it to work.

Under windows/NSIS I set the destination to "../CustomDir" instead of 
$CustomDir.
With this and a custom nsis script which knows the location it is possible to 
run CPack.

In the NSIS script I've the following
Var $CustomDir="@CPACK_TEMPORARY_DIRECTORY@\..\CustomDir"

After this I can install files from this directory too.

The directory content after the preinstall:
.../_CPack_Packages/win32/NSIS/myproject.1.0.0.1/
.../_CPack_Packages/win32/NSIS/CustomDir/
.../_CPack_Packages/win32/NSIS/project.nsi
.
.
.

@Eric, @David: Thank you very much

Best Regards


Am 22.05.2012 um 00:38 schrieb Eric Noulard :

> 2012/5/21 David Cole :
>> On Mon, May 21, 2012 at 2:05 PM,  wrote:
>>> 
>>> But what about other systems like linux. If I have an executable and
>>> shared libraries for example.
>>> Then it is possible to install it under /opt/myproject, but it is not
>>> possible to install the executable under /usr/bin and the shared libraries
>>> under /usr/lib? Or did I misunderstood something?
>> 
>> 
>> But you don't build an NSIS installer based on those.
> 
> And installing lib in /usr/lib and exe in /usr/bin IS possible
> because the 2 path shares the /usr prefix.
> 
> On Linux if you build an RPM or DEB package which contains various
> prefix (/usr /opt etc..) you either get a non relocatable package
> or decide that some files are "special" like config files.
> 
> but David is right this does not work with NSIS.
> 
>>> Sorry, for simple installers the default NSIS template is great, but for
>>> customized ones it seems to be very difficult, isn't it?
> 
> As difficult as it is with NSIS alone :-]
> 
>> Yes, you're correct. It takes some effort if you are not installing
>> everything underneath the directory that the end user chooses for your final
>> location.
>> 
>> It's quite good for "simple installers" and "component-based installers" --
>> beyond that, and especially putting things outside the location chosen by
>> the end user ... you're on your own.
> 
> If you do have 2 separate unrelated installation prefixes
> may be you can just build 2 NSIS installers
> (which contains only one prefix)
> using CPack twice out of 2 differents configurations of the same project
> 
> Or craft your own project.nsi file.
> 
> -- 
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.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

[CMake] Undefine a project()

[Robert Dailey]

Hi,

I was wondering if there is a way to undefined a project(). I want to do
this to prevent projects from being included in a solution when I generate
for Visual Studio. Example:

project( A )
add_executable( A a.cpp )
project( B )
add_executable( B b.cpp )
add_executable( C c.cpp )

I don't want B to be in A's solution when I open A.sln. I'm assuming this
is the behavior, unless project(B) call cancels out project(A)?

Also, I don't want project C to appear in either A or B solutions.

The reason why I'm doing this is because I have setup my CMake scripts to
allow a solution file to be generated for executables (so I can open each
executable solution in different instances of visual studio, with ONLY that
executable + dependency projects in it). However, since sometimes multiple
executable projects can be defined in the same directory, or other
libraries that aren't a dependency of that executable, I do not want those
to be included in the project().
--

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] different assemblers in single build?

[Yuri Timenkov]

Hi,

You should have either 2 build trees or use custom commands.
If you have a lot of files you should go first way.
To ease development you may compile other tree using external project.
Unfortunately external project is not rebuilt if its sources changed. You
have to do it manually.

On Fri, May 11, 2012 at 8:12 PM, Alexey Istomin  wrote:

> Hi all,
>
> Is it possible to use different assemblers in single build with CMake?
>
> I try to use CMake for building embedded application - statically linked
> elf file.
> Main CPU has 2 cores: general-purpose MIPS based core and DSP. Project has
> simple structure: main dir contains asm and C sources for Mips core,
> dsp-lib subdir has only asm sources for DSP core:
>
> main/
>crt0-mips.s
>main.c
>...
>dsp-lib/
>fft.s
>
>
> GCC compiler and assembler are used for Mips sources, special assembler
> (dspasm) based on gnu should be used for DSP. Main should be linked with
> dsp lib into single elf file.
> I can successfully build main app without dsp-lib. But when I try to add
> dsp-lib subdir and set dspadm as assembler, CMake still uses mips-asm in
> the dsp-lib. Is it any solution?
>
> Thanks a lot
> 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
>
--

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] Why is Ninja generator disabled by default?

[Bill Hoffman]

On 5/22/2012 7:35 AM, Richard Wackerbarth wrote:

One of the differences that shows up in the dashboard is that there is a
compile test which passes with normal Unix file paths, but fails when
there is a space in one of the directory names. Perhaps we need to add
an explicit test for everyone, ninja or otherwise, to test that compiles
work with spaces in the path. I have a feeling that we may find
additional failures.
Pretty much all of the dashboards run at kitware have spaces in the 
path, and there is already a test like that.   What test are you talking 
about?  I am pretty sure ninja is ok with spaces.


-Bill
--

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] fixup_bundle() doesn't like libglut.3.dylib

[Michael Jackson]

It seems that this library is ONLY installed with Xcode which leads me to 
believe that libclparser.dylib should ONLY be used during development and is 
NOT a deployable library. Yes there are all sorts of ideas about copying it 
from Snow Leopard but there are both technical and legal issues surrounding 
someone other than Apple distributing that library.
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On May 22, 2012, at 11:54 AM, Joe Ping-Lin Hsiao wrote:

> My Lion has OpenCL framework too. But if you go down the path, there
> is no 'libclparser.dylib' in
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/,
> while it exits in Snow Leopard.
> 
> And by googling ImageMagick and libclparser.dylib, I found people
> having this issue as well. The solution I see so far is to copy the
> .dylib into Lion.
> 
> -Joe
> 
> On Tue, May 22, 2012 at 11:35 AM, Michael Jackson
>  wrote:
>> You have a bad install of Lion (OS X 10.7.x). I just checked 3 different 
>> Lion machines and ALL have OpenCL.framework installed. So I would suspect 
>> your Lion Machine. Lion uses OpenCL for lots of system level calls so a Lion 
>> Install without OpenCL is just plain Broken.
>> 
>> ___
>> Mike JacksonPrincipal Software Engineer
>> BlueQuartz SoftwareDayton, Ohio
>> mike.jack...@bluequartz.net  www.bluequartz.net
>> 
>> On May 22, 2012, at 11:18 AM, Joe Ping-Lin Hsiao wrote:
>> 
>>> Sorry I forgot to mention what the framework is. I believe the OpenCL
>>> framework is from MacOS since I checked two Snow Leopard machines and
>>> both have the framework.
>>> 
>>> I am building my program in Snow Leopard. The program uses a library
>>> called 'ImageMagick', which uses the OpenCL framework. In Snow
>>> Leopard, I don't have to do anything special to OpenCL. It is just
>>> like any other system library, and my bundle and installer work fine
>>> in Snow Leopard.
>>> 
>>> The problem is the OpenCL framework is not included in Lion (MacOS
>>> 10.7). I don't know why Apple changed that. So my program would crash
>>> if running in Lion.
>>> My work around was to copy 'libclparser.dylib' into my bundle and
>>> manually change it's install_name, and also the one used by
>>> ImageMagick. Luckily it works. Now I am trying to make CMake to do it.
>>> 
>>> 
>>> On Tue, May 22, 2012 at 10:48 AM, David Cole  wrote:
 My previous email was your first hint that this might not be a good idea.
 
 This error message is the second hint that this might not be a good idea.
 
 You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
 fixup_bundle. That will recursively copy the framework into the bundle
 rather than selectively copying just the framework library and its
 "Resources" folder.
 
 I am very hesitant to recommend copying a "/System" framework into a bundle
 without knowing more details about where that framework came from.
 
 
 On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
 wrote:
> 
> After setting the framework type to 'other', the framework structure
> is copied into my bundle, including the file OpenCL, but missing
> libclparser.dylib.
> 
> And I got the following errors:
> 
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: CISMM_VIDEO
> CPack: - Install project: CISMM_VIDEO
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
> 
>  
> resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
> 
> Install or copy the item into the bundle before calling fixup_bundle.
> Or maybe there's a typo or incorrect path in one of the args to
> fixup_bundle?
> 
> CMake Error at /Applications/CMake
> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> (message):
>  cannot fixup an item that is not in the b

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Joe Ping-Lin Hsiao]

My Lion has OpenCL framework too. But if you go down the path, there
is no 'libclparser.dylib' in
/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/,
while it exits in Snow Leopard.

And by googling ImageMagick and libclparser.dylib, I found people
having this issue as well. The solution I see so far is to copy the
.dylib into Lion.

-Joe

On Tue, May 22, 2012 at 11:35 AM, Michael Jackson
 wrote:
> You have a bad install of Lion (OS X 10.7.x). I just checked 3 different Lion 
> machines and ALL have OpenCL.framework installed. So I would suspect your 
> Lion Machine. Lion uses OpenCL for lots of system level calls so a Lion 
> Install without OpenCL is just plain Broken.
>
> ___
> Mike Jackson                    Principal Software Engineer
> BlueQuartz Software                            Dayton, Ohio
> mike.jack...@bluequartz.net              www.bluequartz.net
>
> On May 22, 2012, at 11:18 AM, Joe Ping-Lin Hsiao wrote:
>
>> Sorry I forgot to mention what the framework is. I believe the OpenCL
>> framework is from MacOS since I checked two Snow Leopard machines and
>> both have the framework.
>>
>> I am building my program in Snow Leopard. The program uses a library
>> called 'ImageMagick', which uses the OpenCL framework. In Snow
>> Leopard, I don't have to do anything special to OpenCL. It is just
>> like any other system library, and my bundle and installer work fine
>> in Snow Leopard.
>>
>> The problem is the OpenCL framework is not included in Lion (MacOS
>> 10.7). I don't know why Apple changed that. So my program would crash
>> if running in Lion.
>> My work around was to copy 'libclparser.dylib' into my bundle and
>> manually change it's install_name, and also the one used by
>> ImageMagick. Luckily it works. Now I am trying to make CMake to do it.
>>
>>
>> On Tue, May 22, 2012 at 10:48 AM, David Cole  wrote:
>>> My previous email was your first hint that this might not be a good idea.
>>>
>>> This error message is the second hint that this might not be a good idea.
>>>
>>> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
>>> fixup_bundle. That will recursively copy the framework into the bundle
>>> rather than selectively copying just the framework library and its
>>> "Resources" folder.
>>>
>>> I am very hesitant to recommend copying a "/System" framework into a bundle
>>> without knowing more details about where that framework came from.
>>>
>>>
>>> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
>>> wrote:

 After setting the framework type to 'other', the framework structure
 is copied into my bundle, including the file OpenCL, but missing
 libclparser.dylib.

 And I got the following errors:

 CPack: Create package using DragNDrop
 CPack: Install projects
 CPack: - Run preinstall target for: CISMM_VIDEO
 CPack: - Install project: CISMM_VIDEO
 resolving
 /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
  // print out by me
 resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
                             // print out by me
 resolving
 /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
  // print out by me
 resolving
 /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
  // print out by me
 resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
                             // print out by me
  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'

  resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'

 Install or copy the item into the bundle before calling fixup_bundle.
 Or maybe there's a typo or incorrect path in one of the args to
 fixup_bundle?

 CMake Error at /Applications/CMake
 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
 (message):
  cannot fixup an item that is not in the bundle...
 Call Stack (most recent call first):
  /Applications/CMake
 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
 (fixup_bundle_item)
  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17
 (fixup_bundle)
  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)


 CPack Error: Error when generating package: CISMM_VIDEO
 make: *** [package] Error 1



 On Tue, May 22, 2012 at 6:53 AM, David Cole 
 wrote:
> Yes, it's possible. But I would only advise it if you do it on a
> per-framework basis, you built & installed it yourself, and you know for
> certain that the framework in question works fine when moved from its
> "/System/Library" location.
>
> Is this an O

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Michael Jackson]

You have a bad install of Lion (OS X 10.7.x). I just checked 3 different Lion 
machines and ALL have OpenCL.framework installed. So I would suspect your Lion 
Machine. Lion uses OpenCL for lots of system level calls so a Lion Install 
without OpenCL is just plain Broken.

___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On May 22, 2012, at 11:18 AM, Joe Ping-Lin Hsiao wrote:

> Sorry I forgot to mention what the framework is. I believe the OpenCL
> framework is from MacOS since I checked two Snow Leopard machines and
> both have the framework.
> 
> I am building my program in Snow Leopard. The program uses a library
> called 'ImageMagick', which uses the OpenCL framework. In Snow
> Leopard, I don't have to do anything special to OpenCL. It is just
> like any other system library, and my bundle and installer work fine
> in Snow Leopard.
> 
> The problem is the OpenCL framework is not included in Lion (MacOS
> 10.7). I don't know why Apple changed that. So my program would crash
> if running in Lion.
> My work around was to copy 'libclparser.dylib' into my bundle and
> manually change it's install_name, and also the one used by
> ImageMagick. Luckily it works. Now I am trying to make CMake to do it.
> 
> 
> On Tue, May 22, 2012 at 10:48 AM, David Cole  wrote:
>> My previous email was your first hint that this might not be a good idea.
>> 
>> This error message is the second hint that this might not be a good idea.
>> 
>> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
>> fixup_bundle. That will recursively copy the framework into the bundle
>> rather than selectively copying just the framework library and its
>> "Resources" folder.
>> 
>> I am very hesitant to recommend copying a "/System" framework into a bundle
>> without knowing more details about where that framework came from.
>> 
>> 
>> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
>> wrote:
>>> 
>>> After setting the framework type to 'other', the framework structure
>>> is copied into my bundle, including the file OpenCL, but missing
>>> libclparser.dylib.
>>> 
>>> And I got the following errors:
>>> 
>>> CPack: Create package using DragNDrop
>>> CPack: Install projects
>>> CPack: - Run preinstall target for: CISMM_VIDEO
>>> CPack: - Install project: CISMM_VIDEO
>>> resolving
>>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>>  // print out by me
>>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>> // print out by me
>>> resolving
>>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>>  // print out by me
>>> resolving
>>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>>  // print out by me
>>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>> // print out by me
>>>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
>>>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
>>> 
>>>  
>>> resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
>>> 
>>> Install or copy the item into the bundle before calling fixup_bundle.
>>> Or maybe there's a typo or incorrect path in one of the args to
>>> fixup_bundle?
>>> 
>>> CMake Error at /Applications/CMake
>>> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
>>> (message):
>>>  cannot fixup an item that is not in the bundle...
>>> Call Stack (most recent call first):
>>>  /Applications/CMake
>>> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
>>> (fixup_bundle_item)
>>>  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17
>>> (fixup_bundle)
>>>  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)
>>> 
>>> 
>>> CPack Error: Error when generating package: CISMM_VIDEO
>>> make: *** [package] Error 1
>>> 
>>> 
>>> 
>>> On Tue, May 22, 2012 at 6:53 AM, David Cole 
>>> wrote:
 Yes, it's possible. But I would only advise it if you do it on a
 per-framework basis, you built & installed it yourself, and you know for
 certain that the framework in question works fine when moved from its
 "/System/Library" location.
 
 Is this an OpenCL that you built yourself, or did it come from some
 package
 manager?
 
 The set of "type" values that GetPrerequisites assigns to files are:
   set(type "system")
   set(type "embedded")
   set(type "local")
   set(type "other")
 
 "system" means never copy, never fixup
 "embedded" means it will be inside the app bundle, and may be addressed
 relative to @executable_path after fixup_bundle is done
 "local" means it is in exactly the same dir

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[David Cole]

I have Lion 10.7.4 on my laptop and I do have an OpenCL.framework in
"/System/Library/Frameworks/OpenCL.framework/"

So the real question is: why doesn't it just work for you? Because it
should work without you having to copy the OpenCL framework into your
bundle.

Especially if the OpenCL.framework is part of the root OS installation. If
that's the case, it may not even be legal to copy that framework into your
bundle and then redistribute it.


On Tue, May 22, 2012 at 11:18 AM, Joe Ping-Lin Hsiao wrote:

> Sorry I forgot to mention what the framework is. I believe the OpenCL
> framework is from MacOS since I checked two Snow Leopard machines and
> both have the framework.
>
> I am building my program in Snow Leopard. The program uses a library
> called 'ImageMagick', which uses the OpenCL framework. In Snow
> Leopard, I don't have to do anything special to OpenCL. It is just
> like any other system library, and my bundle and installer work fine
> in Snow Leopard.
>
> The problem is the OpenCL framework is not included in Lion (MacOS
> 10.7). I don't know why Apple changed that. So my program would crash
> if running in Lion.
> My work around was to copy 'libclparser.dylib' into my bundle and
> manually change it's install_name, and also the one used by
> ImageMagick. Luckily it works. Now I am trying to make CMake to do it.
>
>
> On Tue, May 22, 2012 at 10:48 AM, David Cole 
> wrote:
> > My previous email was your first hint that this might not be a good idea.
> >
> > This error message is the second hint that this might not be a good idea.
> >
> > You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before
> calling
> > fixup_bundle. That will recursively copy the framework into the bundle
> > rather than selectively copying just the framework library and its
> > "Resources" folder.
> >
> > I am very hesitant to recommend copying a "/System" framework into a
> bundle
> > without knowing more details about where that framework came from.
> >
> >
> > On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
> > wrote:
> >>
> >> After setting the framework type to 'other', the framework structure
> >> is copied into my bundle, including the file OpenCL, but missing
> >> libclparser.dylib.
> >>
> >> And I got the following errors:
> >>
> >> CPack: Create package using DragNDrop
> >> CPack: Install projects
> >> CPack: - Run preinstall target for: CISMM_VIDEO
> >> CPack: - Install project: CISMM_VIDEO
> >> resolving
> >>
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> >>  // print out by me
> >> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> >> // print out by me
> >> resolving
> >>
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> >>  // print out by me
> >> resolving
> >>
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> >>  // print out by me
> >> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> >> // print out by me
> >>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
> >>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
> >>
> >>
>  
> resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
> >>
> >> Install or copy the item into the bundle before calling fixup_bundle.
> >> Or maybe there's a typo or incorrect path in one of the args to
> >> fixup_bundle?
> >>
> >> CMake Error at /Applications/CMake
> >> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> >> (message):
> >>  cannot fixup an item that is not in the bundle...
> >> Call Stack (most recent call first):
> >>  /Applications/CMake
> >> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
> >> (fixup_bundle_item)
> >>  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17
> >> (fixup_bundle)
> >>  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)
> >>
> >>
> >> CPack Error: Error when generating package: CISMM_VIDEO
> >> make: *** [package] Error 1
> >>
> >>
> >>
> >> On Tue, May 22, 2012 at 6:53 AM, David Cole 
> >> wrote:
> >> > Yes, it's possible. But I would only advise it if you do it on a
> >> > per-framework basis, you built & installed it yourself, and you know
> for
> >> > certain that the framework in question works fine when moved from its
> >> > "/System/Library" location.
> >> >
> >> > Is this an OpenCL that you built yourself, or did it come from some
> >> > package
> >> > manager?
> >> >
> >> > The set of "type" values that GetPrerequisites assigns to files are:
> >> >   set(type "system")
> >> >   set(type "embedded")
> >> >   set(type "local")
> >> >   set(type "other")
> >> >
> >> > "system" means never copy, never fixup
> >> > "embedded" means it will be inside the app bundle, and may be
> addressed
> >> > relative to @executable_path after fixup_bundle is done
> >> > "lo

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Joe Ping-Lin Hsiao]

Sorry I forgot to mention what the framework is. I believe the OpenCL
framework is from MacOS since I checked two Snow Leopard machines and
both have the framework.

I am building my program in Snow Leopard. The program uses a library
called 'ImageMagick', which uses the OpenCL framework. In Snow
Leopard, I don't have to do anything special to OpenCL. It is just
like any other system library, and my bundle and installer work fine
in Snow Leopard.

The problem is the OpenCL framework is not included in Lion (MacOS
10.7). I don't know why Apple changed that. So my program would crash
if running in Lion.
My work around was to copy 'libclparser.dylib' into my bundle and
manually change it's install_name, and also the one used by
ImageMagick. Luckily it works. Now I am trying to make CMake to do it.


On Tue, May 22, 2012 at 10:48 AM, David Cole  wrote:
> My previous email was your first hint that this might not be a good idea.
>
> This error message is the second hint that this might not be a good idea.
>
> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
> fixup_bundle. That will recursively copy the framework into the bundle
> rather than selectively copying just the framework library and its
> "Resources" folder.
>
> I am very hesitant to recommend copying a "/System" framework into a bundle
> without knowing more details about where that framework came from.
>
>
> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
> wrote:
>>
>> After setting the framework type to 'other', the framework structure
>> is copied into my bundle, including the file OpenCL, but missing
>> libclparser.dylib.
>>
>> And I got the following errors:
>>
>> CPack: Create package using DragNDrop
>> CPack: Install projects
>> CPack: - Run preinstall target for: CISMM_VIDEO
>> CPack: - Install project: CISMM_VIDEO
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>                             // print out by me
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>  // print out by me
>> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
>>                             // print out by me
>>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
>>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
>>
>>  resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
>>
>> Install or copy the item into the bundle before calling fixup_bundle.
>> Or maybe there's a typo or incorrect path in one of the args to
>> fixup_bundle?
>>
>> CMake Error at /Applications/CMake
>> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
>> (message):
>>  cannot fixup an item that is not in the bundle...
>> Call Stack (most recent call first):
>>  /Applications/CMake
>> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
>> (fixup_bundle_item)
>>  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17
>> (fixup_bundle)
>>  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)
>>
>>
>> CPack Error: Error when generating package: CISMM_VIDEO
>> make: *** [package] Error 1
>>
>>
>>
>> On Tue, May 22, 2012 at 6:53 AM, David Cole 
>> wrote:
>> > Yes, it's possible. But I would only advise it if you do it on a
>> > per-framework basis, you built & installed it yourself, and you know for
>> > certain that the framework in question works fine when moved from its
>> > "/System/Library" location.
>> >
>> > Is this an OpenCL that you built yourself, or did it come from some
>> > package
>> > manager?
>> >
>> > The set of "type" values that GetPrerequisites assigns to files are:
>> >   set(type "system")
>> >   set(type "embedded")
>> >   set(type "local")
>> >   set(type "other")
>> >
>> > "system" means never copy, never fixup
>> > "embedded" means it will be inside the app bundle, and may be addressed
>> > relative to @executable_path after fixup_bundle is done
>> > "local" means it is in exactly the same directory as the executable
>> > "other" is everything else
>> >
>> > So, in your case, you'd want to match on the file path beginning and set
>> > the
>> > type to "other". Just add another chunk inside your override function
>> > that
>> > looks like this:
>> >
>> >      if(resolved_file MATCHES
>> > "^/System/Library/Frameworks/OpenCL.framework")
>> >        message("resolving ${resolved_file} as other")
>> >        set(${type_var} other PARENT_SCOPE)
>> >      endif()
>> >
>> >
>> > HTH,
>> > David
>> >
>> >
>> > On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao 
>> > wrote:
>> >>
>> >> Thanks, David. It works!
>> >>
>> >> Is it possible to do the other way around?
>> >> I want fixup_bundl

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Clinton Stimpson]

If you compile/install these 3rd party libraries yourself, and compile against 
them, then they are automatically recognized as non-system libraries.  That's 
the approach I take instead of trying to overload the behavior to treat some 
system libraries as non-system ones.

Clint

On Tuesday, May 22, 2012 10:48:33 AM David Cole wrote:
> My previous email was your first hint that this might not be a good idea.
> 
> This error message is the second hint that this might not be a good idea.
> 
> You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
> fixup_bundle. That will recursively copy the framework into the bundle
> rather than selectively copying just the framework library and its
> "Resources" folder.
> 
> I am very hesitant to recommend copying a "/System" framework into a bundle
> without knowing more details about where that framework came from.
> 
> On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao 
wrote:
> > After setting the framework type to 'other', the framework structure
> > is copied into my bundle, including the file OpenCL, but missing
> > libclparser.dylib.
> > 
> > And I got the following errors:
> > 
> > CPack: Create package using DragNDrop
> > CPack: Install projects
> > CPack: - Run preinstall target for: CISMM_VIDEO
> > CPack: - Install project: CISMM_VIDEO
> > resolving
> > /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclpa
> > rser.dylib> 
> >  // print out by me
> > 
> > resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> > 
> > // print out by
> > me
> > 
> > resolving
> > /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclpa
> > rser.dylib> 
> >  // print out by me
> > 
> > resolving
> > /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclpa
> > rser.dylib> 
> >  // print out by me
> > 
> > resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> > 
> > // print out by
> > me
> >  
> >  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
> >  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
> >  
> >  resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Ve
> >  rsions/A/Libraries/libclparser.dylib'> 
> > Install or copy the item into the bundle before calling fixup_bundle.
> > Or maybe there's a typo or incorrect path in one of the args to
> > fixup_bundle?
> > 
> > CMake Error at /Applications/CMake
> > 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> > 
> > (message):
> >  cannot fixup an item that is not in the bundle...
> > 
> > Call Stack (most recent call first):
> >  /Applications/CMake
> > 
> > 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
> > (fixup_bundle_item)
> > 
> >  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17
> >  (fixup_bundle) /Users/phsiao/dev/video/cmake_install.cmake:127
> >  (INCLUDE)
> > 
> > CPack Error: Error when generating package: CISMM_VIDEO
> > make: *** [package] Error 1
> > 
> > 
> > 
> > On Tue, May 22, 2012 at 6:53 AM, David Cole 
> > 
> > wrote:
> > > Yes, it's possible. But I would only advise it if you do it on a
> > > per-framework basis, you built & installed it yourself, and you know
> > > for certain that the framework in question works fine when moved
> > > from its "/System/Library" location.
> > > 
> > > Is this an OpenCL that you built yourself, or did it come from some
> > 
> > package
> > 
> > > manager?
> > > 
> > > The set of "type" values that GetPrerequisites assigns to files are:
> > >   set(type "system")
> > >   set(type "embedded")
> > >   set(type "local")
> > >   set(type "other")
> > > 
> > > "system" means never copy, never fixup
> > > "embedded" means it will be inside the app bundle, and may be
> > > addressed
> > > relative to @executable_path after fixup_bundle is done
> > > "local" means it is in exactly the same directory as the executable
> > > "other" is everything else
> > > 
> > > So, in your case, you'd want to match on the file path beginning and
> > > set> 
> > the
> > 
> > > type to "other". Just add another chunk inside your override
> > > function
> > 
> > that
> > 
> > > looks like this:
> > >  if(resolved_file MATCHES
> > > 
> > > "^/System/Library/Frameworks/OpenCL.framework")
> > > 
> > >message("resolving ${resolved_file} as other")
> > >set(${type_var} other PARENT_SCOPE)
> > >  
> > >  endif()
> > > 
> > > HTH,
> > > David
> > > 
> > > 
> > > On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao
> > > 
> > > 
> > > wrote:
> > >> Thanks, David. It works!
> > >> 
> > >> Is it possible to do the other way around?
> > >> I want fixup_bundle() to treat
> > 
> > /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclpa
> > rser.dylib> 
> > >> as an external library instead of a system lib. I looked at
> > >> functions
> > >> in 

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Michael Jackson]

I too am curios as to why you need to copy ANYTHING from /System/Frameworks. 
Typically if a framework is in there then it is installed on OS X BY Apple. If 
you are deploying your application to an OS X machine that does NOT have this 
file then the version of the operating system (OS X) will NOT support that 
framework. So are you compiling some OpenCL framework yourself and placing it 
in /System/Frameworks which would go against EVERY warning that Apple tells you 
to do.
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On May 22, 2012, at 10:33 AM, Joe Ping-Lin Hsiao wrote:

> After setting the framework type to 'other', the framework structure
> is copied into my bundle, including the file OpenCL, but missing
> libclparser.dylib.
> 
> And I got the following errors:
> 
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: CISMM_VIDEO
> CPack: - Install project: CISMM_VIDEO
> resolving 
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
> resolving 
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> // print out by me
> resolving 
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
>  
> resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
> 
> Install or copy the item into the bundle before calling fixup_bundle.
> Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?
> 
> CMake Error at /Applications/CMake
> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> (message):
>  cannot fixup an item that is not in the bundle...
> Call Stack (most recent call first):
>  /Applications/CMake
> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
> (fixup_bundle_item)
>  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17 (fixup_bundle)
>  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)
> 
> 
> CPack Error: Error when generating package: CISMM_VIDEO
> make: *** [package] Error 1
> 
> 
> 
> On Tue, May 22, 2012 at 6:53 AM, David Cole  wrote:
>> Yes, it's possible. But I would only advise it if you do it on a
>> per-framework basis, you built & installed it yourself, and you know for
>> certain that the framework in question works fine when moved from its
>> "/System/Library" location.
>> 
>> Is this an OpenCL that you built yourself, or did it come from some package
>> manager?
>> 
>> The set of "type" values that GetPrerequisites assigns to files are:
>>   set(type "system")
>>   set(type "embedded")
>>   set(type "local")
>>   set(type "other")
>> 
>> "system" means never copy, never fixup
>> "embedded" means it will be inside the app bundle, and may be addressed
>> relative to @executable_path after fixup_bundle is done
>> "local" means it is in exactly the same directory as the executable
>> "other" is everything else
>> 
>> So, in your case, you'd want to match on the file path beginning and set the
>> type to "other". Just add another chunk inside your override function that
>> looks like this:
>> 
>>  if(resolved_file MATCHES
>> "^/System/Library/Frameworks/OpenCL.framework")
>>message("resolving ${resolved_file} as other")
>>set(${type_var} other PARENT_SCOPE)
>>  endif()
>> 
>> 
>> HTH,
>> David
>> 
>> 
>> On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao 
>> wrote:
>>> 
>>> Thanks, David. It works!
>>> 
>>> Is it possible to do the other way around?
>>> I want fixup_bundle() to treat
>>> 
>>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>>> as an external library instead of a system lib. I looked at functions
>>> in BundleUtilities.cmake and GetPrerequisites.cmake but didn't get any
>>> clue how to do that.
>>> 
>>> Thanks,
>>> Joe
>>> 
>>> On Mon, May 14, 2012 at 8:47 PM, David Cole 
>>> wrote:
 Rather than just doing a "fixup_bundle" as an INSTALL(CODE snippet, put
 it
 in a separate CMake script, and use install(SCRIPT to execute it. You
 can
 configure the script with configure_file if you need to put stuff in it
 that
 depends on CMake variables.
 
 Then, in your script:
 
   # Define the function before including BundleUtilities:
   function(gp_resolved_file_type_override resolved_file type_var)
  

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[David Cole]

My previous email was your first hint that this might not be a good idea.

This error message is the second hint that this might not be a good idea.

You can try setting "BU_COPY_FULL_FRAMEWORK_CONTENTS" to ON before calling
fixup_bundle. That will recursively copy the framework into the bundle
rather than selectively copying just the framework library and its
"Resources" folder.

I am very hesitant to recommend copying a "/System" framework into a bundle
without knowing more details about where that framework came from.


On Tue, May 22, 2012 at 10:33 AM, Joe Ping-Lin Hsiao wrote:

> After setting the framework type to 'other', the framework structure
> is copied into my bundle, including the file OpenCL, but missing
> libclparser.dylib.
>
> And I got the following errors:
>
> CPack: Create package using DragNDrop
> CPack: Install projects
> CPack: - Run preinstall target for: CISMM_VIDEO
> CPack: - Install project: CISMM_VIDEO
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>  // print out by me
> resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
> // print out by me
>  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
>  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
>
>  
> resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'
>
> Install or copy the item into the bundle before calling fixup_bundle.
> Or maybe there's a typo or incorrect path in one of the args to
> fixup_bundle?
>
> CMake Error at /Applications/CMake
> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> (message):
>  cannot fixup an item that is not in the bundle...
> Call Stack (most recent call first):
>  /Applications/CMake
> 2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
> (fixup_bundle_item)
>  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17 (fixup_bundle)
>  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)
>
>
> CPack Error: Error when generating package: CISMM_VIDEO
> make: *** [package] Error 1
>
>
>
> On Tue, May 22, 2012 at 6:53 AM, David Cole 
> wrote:
> > Yes, it's possible. But I would only advise it if you do it on a
> > per-framework basis, you built & installed it yourself, and you know for
> > certain that the framework in question works fine when moved from its
> > "/System/Library" location.
> >
> > Is this an OpenCL that you built yourself, or did it come from some
> package
> > manager?
> >
> > The set of "type" values that GetPrerequisites assigns to files are:
> >   set(type "system")
> >   set(type "embedded")
> >   set(type "local")
> >   set(type "other")
> >
> > "system" means never copy, never fixup
> > "embedded" means it will be inside the app bundle, and may be addressed
> > relative to @executable_path after fixup_bundle is done
> > "local" means it is in exactly the same directory as the executable
> > "other" is everything else
> >
> > So, in your case, you'd want to match on the file path beginning and set
> the
> > type to "other". Just add another chunk inside your override function
> that
> > looks like this:
> >
> >  if(resolved_file MATCHES
> > "^/System/Library/Frameworks/OpenCL.framework")
> >message("resolving ${resolved_file} as other")
> >set(${type_var} other PARENT_SCOPE)
> >  endif()
> >
> >
> > HTH,
> > David
> >
> >
> > On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao 
> > wrote:
> >>
> >> Thanks, David. It works!
> >>
> >> Is it possible to do the other way around?
> >> I want fixup_bundle() to treat
> >>
> >>
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> >> as an external library instead of a system lib. I looked at functions
> >> in BundleUtilities.cmake and GetPrerequisites.cmake but didn't get any
> >> clue how to do that.
> >>
> >> Thanks,
> >> Joe
> >>
> >> On Mon, May 14, 2012 at 8:47 PM, David Cole 
> >> wrote:
> >> > Rather than just doing a "fixup_bundle" as an INSTALL(CODE snippet,
> put
> >> > it
> >> > in a separate CMake script, and use install(SCRIPT to execute it. You
> >> > can
> >> > configure the script with configure_file if you need to put stuff in
> it
> >> > that
> >> > depends on CMake variables.
> >> >
> >> > Then, in your script:
> >> >
> >> >   # Define the function before including BundleUtilities:
> >> >   function(gp_resolved_file_type_override resolved_file type_var)
> >> > if(resolved_file MATCHES "^/usr/X11/lib")
> >> >   message("resolving ${resolved_file} as system")
> >> >

Re: [CMake] fixup_bundle() doesn't like libglut.3.dylib

[Joe Ping-Lin Hsiao]

After setting the framework type to 'other', the framework structure
is copied into my bundle, including the file OpenCL, but missing
libclparser.dylib.

And I got the following errors:

CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: CISMM_VIDEO
CPack: - Install project: CISMM_VIDEO
resolving 
/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
 // print out by me
resolving 
/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving 
/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
 // print out by me
resolving /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
 // print out by me
  exe_dotapp_dir/='/Users/phsiao/dev/video/video_spot_tracker.app/'
  item_substring='/System/Library/Frameworks/OpenCL.framework/Ver'
  
resolved_embedded_item='/System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib'

Install or copy the item into the bundle before calling fixup_bundle.
Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?

CMake Error at /Applications/CMake
2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
(message):
  cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
  /Applications/CMake
2.8-7.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
(fixup_bundle_item)
  /Users/phsiao/dev/video/video_spot_tracker_install.cmake:17 (fixup_bundle)
  /Users/phsiao/dev/video/cmake_install.cmake:127 (INCLUDE)


CPack Error: Error when generating package: CISMM_VIDEO
make: *** [package] Error 1



On Tue, May 22, 2012 at 6:53 AM, David Cole  wrote:
> Yes, it's possible. But I would only advise it if you do it on a
> per-framework basis, you built & installed it yourself, and you know for
> certain that the framework in question works fine when moved from its
> "/System/Library" location.
>
> Is this an OpenCL that you built yourself, or did it come from some package
> manager?
>
> The set of "type" values that GetPrerequisites assigns to files are:
>   set(type "system")
>   set(type "embedded")
>   set(type "local")
>   set(type "other")
>
> "system" means never copy, never fixup
> "embedded" means it will be inside the app bundle, and may be addressed
> relative to @executable_path after fixup_bundle is done
> "local" means it is in exactly the same directory as the executable
> "other" is everything else
>
> So, in your case, you'd want to match on the file path beginning and set the
> type to "other". Just add another chunk inside your override function that
> looks like this:
>
>      if(resolved_file MATCHES
> "^/System/Library/Frameworks/OpenCL.framework")
>        message("resolving ${resolved_file} as other")
>        set(${type_var} other PARENT_SCOPE)
>      endif()
>
>
> HTH,
> David
>
>
> On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao 
> wrote:
>>
>> Thanks, David. It works!
>>
>> Is it possible to do the other way around?
>> I want fixup_bundle() to treat
>>
>> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
>> as an external library instead of a system lib. I looked at functions
>> in BundleUtilities.cmake and GetPrerequisites.cmake but didn't get any
>> clue how to do that.
>>
>> Thanks,
>> Joe
>>
>> On Mon, May 14, 2012 at 8:47 PM, David Cole 
>> wrote:
>> > Rather than just doing a "fixup_bundle" as an INSTALL(CODE snippet, put
>> > it
>> > in a separate CMake script, and use install(SCRIPT to execute it. You
>> > can
>> > configure the script with configure_file if you need to put stuff in it
>> > that
>> > depends on CMake variables.
>> >
>> > Then, in your script:
>> >
>> >   # Define the function before including BundleUtilities:
>> >   function(gp_resolved_file_type_override resolved_file type_var)
>> >     if(resolved_file MATCHES "^/usr/X11/lib")
>> >       message("resolving ${resolved_file} as system")
>> >       set(${type_var} system PARENT_SCOPE)
>> >     endif()
>> >   endfunction()
>> >
>> >   include(BundleUtilities)
>> >
>> >   fixup_bundle( ... )
>> >
>> > ParaView's install rules on the Mac do something like this, if you want
>> > to
>> > look at some example code.
>> >
>> >
>> > HTH,
>> > David
>> >
>> >
>> > On Mon, May 14, 2012 at 5:27 PM, Joe Ping-Lin Hsiao 
>> > wrote:
>> >>
>> >> Thanks, this is exactly what I need.
>> >>
>> >> Just one question.  Why the function gp_resolved_file_type_override()
>> >> cannot be seen if it is implemented in my project's CMakeLists.txt? I
>> >> have to add it in GetPrerequisite.cmake module, but that's not good.
>> >>
>> >> Thanks,
>> >> Joe
>> >>
>> >> On Mon, May 7, 2012 at 11:04 AM, David Cole 
>> >> wrote:
>> >> > /usr/X11/lib/libglut.dylib should probably be consi

[CMake] Select a project for building only for a specific configuration

[Cristian Cocheci]

I have seen this question asked before, but did not find any good answer for 
it, so I was hoping that meanwhile someone might have found a good solution.
I need to select one of the projects for building in our Visual Studio solution 
(that contains ~ 20 total projects) only in a certain configuration (e.g. 
Release). Our nightly builds run on a Jenkins build server so I need CMake to 
output the generators with that specific project selected for building only in 
Release. Has anyone found a good way to do this?

Thanks,
Cristian--

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] the list parameter passed to function

[Petr Kmoch]

Hi,

try as I might, I can't see a difference between the output and
expected output. Perhaps a copy-paste error?

Petr

On Tue, May 22, 2012 at 3:07 AM, Marmot Ken  wrote:
> here is the function :
>
> FUNCTION( Append_headers_to_src_list  src_list_out src_list_in
> header_file_path_in )
>     MESSAGE( src_list_in  " : ${src_list_in}" )
>     FILE( GLOB_RECURSE TEMP_LIST ${header_file_path_in}/*.h )
>     SET( ${src_list_out} ${src_list_in} ${TEMP_LIST} PARENT_SCOPE )
> ENDFUNCTION( Append_headers_to_src_list
>
>
> here is the place where the function is invoked:
>
> AUX_SOURCE_DIRECTORY( . SRC_LIST  )
> MESSAGE( SRC_LIST  " : ${SRC_LIST} " )
>
> Append_headers_to_src_list( SRC_LIST  ${SRC_LIST}
> ${CMAKE_SOURCE_DIR}/include/test  )
>
> here is output　：
>
> SRC_LIST : ./a.cpp;./c.cpp;./main.cpp
> src_list_in : ./a.cpp
>
> Output expected :
>
> SRC_LIST : ./a.cpp;./c.cpp;./main.cpp
> src_list_in : ./a.cpp
>
> Ｑｕｅｓｔｉｏｎ：
> 　 <1>  how to get expected Output ?
>     <2>  why ?
>
> 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
--

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] Why is Ninja generator disabled by default?

[Richard Wackerbarth]

One of the differences that shows up in the dashboard is that there is a 
compile test which passes with normal Unix file paths, but fails when there is 
a space in one of the directory names. Perhaps we need to add an explicit test 
for everyone, ninja or otherwise, to test that compiles work with spaces in the 
path. I have a feeling that we may find additional failures.

On May 22, 2012, at 6:02 AM, David Cole wrote:

> Please take a look at the CMake dashboard:
> 
>   http://open.cdash.org/index.php?project=CMake
> 
> I will allow the ninja generator to be enabled by default after interested 
> parties fix all the failing tests in the "Nightly Expected" section related 
> to the ninja generator submissions.
> 
> Honestly, I was opposed to the ninja generator being merged to 'master' and 
> enabled at all because of the failing tests on our dashboard. Luckily for all 
> you ninja fans out there, I do not have dictator powers. ;-)
> 
> 
> 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] Packaging : Debug + Release together

[Nicholas Yue]

On 22/05/12 18:20, Kfir Lavi wrote:


I would just compile it twice and create my-debug.rpm and my.rpm
Is that a viable solution for you?

I am gravitating towards that option.

Regards

--
Nicholas Yue
Graphics - RenderMan, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
Management - Recruitment, career management
http://www.proceduralinsight.com/
http://au.linkedin.com/in/nicholasyue

--

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] Why is Ninja generator disabled by default?

[David Cole]

Please take a look at the CMake dashboard:

  http://open.cdash.org/index.php?project=CMake

I will allow the ninja generator to be enabled by default after interested
parties fix all the failing tests in the "Nightly Expected" section related
to the ninja generator submissions.

Honestly, I was opposed to the ninja generator being merged to 'master' and
enabled at all because of the failing tests on our dashboard. Luckily for
all you ninja fans out there, I do not have dictator powers. ;-)


David


On Mon, May 21, 2012 at 4:27 PM, Andreas Mohr  wrote:

> Hi,
>
> On Mon, May 21, 2012 at 10:40:03AM -0400, cmake-requ...@cmake.org wrote:
> > From: David Cole 
> > I agree with Bill here -- we cannot turn it on by default until it works
> > sufficiently for typical use cases.
>
> So, what would be needed to turn CMake on by default?
> 'cause it does not "work sufficiently for typical use cases" :->
> 
>
>
> While there might be backwards compatibility reasons for only actually
> having Ninja truly enabled once it truly works (after all after some years
> certain user code may resort to merely checking whether the feature
> is provided or not, rather than doing sufficiently precise checks
> "well, in this CMake pre-beta it actually was still broken,
> and 3 days later they fixed it"),
> I cannot help but wonder whether this configuration (build-time disabling
> rather than a slightly special way of runtime disabling)
> is hindering progress a bit due to artificially limiting developer uptake.
> OTOH people who tend to like playing with certain bleeding edge things
> (like me)
> are actually able to enable it manually - it's just somewhat more
> effort:
>
> > For specialized use cases, if you know you want to turn it on, you can
> > easily re-build a CMake of your own that has it enabled. Simply turn on
> the
> > advanced cache option CMAKE_ENABLE_NINJA when configuring CMake.
>
>
> Andreas Mohr
>
--

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] fixup_bundle() doesn't like libglut.3.dylib

[David Cole]

Yes, it's possible. But I would only advise it if you do it on a
per-framework basis, you built & installed it yourself, and you know for
certain that the framework in question works fine when moved from its
"/System/Library" location.

Is this an OpenCL that you built yourself, or did it come from some package
manager?

The set of "type" values that GetPrerequisites assigns to files are:
  set(type "system")
  set(type "embedded")
  set(type "local")
  set(type "other")

"system" means never copy, never fixup
"embedded" means it will be inside the app bundle, and may be addressed
relative to @executable_path after fixup_bundle is done
"local" means it is in exactly the same directory as the executable
"other" is everything else

So, in your case, you'd want to match on the file path beginning and set
the type to "other". Just add another chunk inside your override function
that looks like this:

 if(resolved_file MATCHES "^/System/Library/Frameworks/OpenCL.framework
")
   message("resolving ${resolved_file} as other")
   set(${type_var} other PARENT_SCOPE)
 endif()


HTH,
David


On Mon, May 21, 2012 at 4:01 PM, Joe Ping-Lin Hsiao wrote:

> Thanks, David. It works!
>
> Is it possible to do the other way around?
> I want fixup_bundle() to treat
>
> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libclparser.dylib
> as an external library instead of a system lib. I looked at functions
> in BundleUtilities.cmake and GetPrerequisites.cmake but didn't get any
> clue how to do that.
>
> Thanks,
> Joe
>
> On Mon, May 14, 2012 at 8:47 PM, David Cole 
> wrote:
> > Rather than just doing a "fixup_bundle" as an INSTALL(CODE snippet, put
> it
> > in a separate CMake script, and use install(SCRIPT to execute it. You can
> > configure the script with configure_file if you need to put stuff in it
> that
> > depends on CMake variables.
> >
> > Then, in your script:
> >
> >   # Define the function before including BundleUtilities:
> >   function(gp_resolved_file_type_override resolved_file type_var)
> > if(resolved_file MATCHES "^/usr/X11/lib")
> >   message("resolving ${resolved_file} as system")
> >   set(${type_var} system PARENT_SCOPE)
> > endif()
> >   endfunction()
> >
> >   include(BundleUtilities)
> >
> >   fixup_bundle( ... )
> >
> > ParaView's install rules on the Mac do something like this, if you want
> to
> > look at some example code.
> >
> >
> > HTH,
> > David
> >
> >
> > On Mon, May 14, 2012 at 5:27 PM, Joe Ping-Lin Hsiao 
> > wrote:
> >>
> >> Thanks, this is exactly what I need.
> >>
> >> Just one question.  Why the function gp_resolved_file_type_override()
> >> cannot be seen if it is implemented in my project's CMakeLists.txt? I
> >> have to add it in GetPrerequisite.cmake module, but that's not good.
> >>
> >> Thanks,
> >> Joe
> >>
> >> On Mon, May 7, 2012 at 11:04 AM, David Cole 
> >> wrote:
> >> > /usr/X11/lib/libglut.dylib should probably be considered a "system
> >> > library" that is not included in your final bundle.
> >> >
> >> > Therefore, all users of your application will have to have the Mac OS
> >> > X version of X installed and available in order to run your program.
> >> > (Is that all Macs nowadays anyway...?)
> >> >
> >> > In order to classify it as a system library, you can provide a CMake
> >> > function named gp_resolved_file_type_override to look for that library
> >> > (probably anything starting with "/usr/X11/lib") and set its type to
> >> > "system" -- that will cause fixup_bundle to ignore it for copying and
> >> > fixup purposes.
> >> >
> >> >
> >> > HTH,
> >> > David
> >> >
> >> >
> >> > On Mon, May 7, 2012 at 10:57 AM, Joe Ping-Lin Hsiao <
> phs...@cs.unc.edu>
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> I use CMake to create an installer for a Mac program which uses GLUT.
> >> >> The GLUT library that the program links against with is
> >> >> /usr/X11/lib/libglut.dylib.
> >> >>
> >> >> When I use fixup_bundle() to create an installer, I get the following
> >> >> error message:
> >> >>
> >> >> install_name_tool: changing install names or rpaths can't be redone
> >> >> for:
> >> >>
> /Users/phsiao/dev/video/video_spot_tracker.app/Contents/MacOS/libglut.3.dylib
> >> >> (for architecture ppc7400) because larger updated load commands do
> not
> >> >> fit (the program must be relinked, and you may need to use -headerpad
> >> >> or -headerpad_max_install_names)
> >> >>
> >> >> The first thing I tried was to add -headerpad_max_install_names and
> >> >> -headerpad to the linker flags, but no success. (Actually
> >> >> -headerpad_max_install_names already exists in CMakeFies/link.txt
> >> >> before I put it in.)
> >> >>
> >> >> The next thing I tried was to add '-arch x86_64' to both CXX_FLAGS
> and
> >> >> LINKER_FLAGS to avoid fixup_bundle() to fix dependencies for
> >> >> architecture ppc7400, but the error remains.
> >> >>
> >> >> Any idea how to get around this?
> >> >>
> >> >> Thanks,
> >> >> Joe
> >> >> --
> >> >>
> >> >> Powered b

Re: [CMake] Packaging : Debug + Release together

[Kfir Lavi]

On Tue, May 22, 2012 at 1:45 AM, Eric Noulard wrote:

> 2012/5/21 Nicholas Yue :
> > Hi,
> >
> >I can build debug and release code by setting the CMAKE_BUILD_TYPE
> > variable.
> >
> >What is the recommend process/workflow if I wish to
> build/install/package
> > both the Debug and Release build into a single e.g. RPM, as part of an
> > automated process (e.g. nightly build) ?
>
> Currently CPack cannot do that out of the box because CMake cannot do
> that either.
> CMake requires 2 build trees for that (at least on Linux)
>
> >How will CPack find the different builds for packaging ?
>
> He won't.
>
> May be it's possible to craft your own CPackConfig.cmake file which would
> refer to the 2 build trees but how would you ensure that there won't
> be any name collision between "debug" and "release" tree?
>
> Shall they be installed in different place /prefix ?
> What would be the layout of the expected unique RPM ?
>
>
>
> --
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.org
> --
>
>
I would just compile it twice and create my-debug.rpm and my.rpm
Is that a viable solution for you?

Regards,
Kfir
--

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