[CMake] SET_TARGET_PROPERTIES question on MacOSX

[Mike Jackson]

On Dec 4, 2007, at 4:46 PM, Félix C. Morency wrote:

> Mike,
>
> Thank you for your precise answer. I will try this tomorrow. I have  
> few other questions for you:
>
> 1.0) Why isn't CMake doing this automatically ?
   CMake will set the "install_path" for you if you use the  
SET_TARGET_PROPERTIES macro. This just applies to libraries that  
CMake builds for you. Xcode would be no different in this respect
>
> 1.1) Is is just a CMake's missing feature or is there any technical  
> issues ? I think QMake does it for you isn't is ?
     See above. Qmake _might_ do it the same way cmake does, by  
setting a bunch of link flags. check with qmake.
>
> 2.0) I'm sure Apple has plenty of reasons for doing libs handling  
> this way but is it only me or this is completly retard ?
     It is "Different". Apple wants the user experience to be easy  
and straight forward. This also includes "installing" programs and  
applications. It should be a Drag-and-Drop process if at all  
possible. There are times when this is just not possible. For MOST  
programs out there, this is absolutely possible. Because Apple would  
like everything to be in a bundled app there needs to be "special"  
install_names (or rpaths) in the libraries. This is the need.
>
> 2.1) I'm not sure but I don't think linux is working this way isn't  
> it ?
No. Linux and to some extent windows do not work this way. Then  
again, windows has "DLL Hell" because all the dlls are just put in  
the same directory. So what happens when your installer puts version  
1 of a library in /usr/local and my installer overwrites your lib  
with version 2? Your app stops working and a lot of finger pointing  
takes place. If you spend the time upfront as a developer to package  
your application properly you avoid having to deal with this problem.

>
> 2.2) Wouldn't it be easier just to install all the libs with CPack  
> in standard location (/usr/lib) if possible ?

See above. NEVER install ANYTHING in /usr/lib on OS X. That is  
reserved for APPLE supplied stuff. If you have to put it somewhere,  
then /usr/local/lib is better. If you have frameworks then put those  
in /Library/Frameworks, but you better have a REALLY good reason for  
putting something in there. Package the App how Apple wants and you  
will find that you spend less time troubleshooting problems on OS X  
and more time coding. You can look at my examples to see how I am  
doing things. You are perfectly allowed to use any of my code in your  
projects. If you make them better I would appreciate knowing.

>
> Libs handling under OSX is a real PITA. I will give you my feedback  
> soon.

It is a PITA when your build system does not properly/easily support  
them. Even in Xcode, it is tricky to get things setup correctly so  
cmake isn't going to be any easier. Examples help. Look at mine. They  
take a lot of the burden off you and should be able to "Do the right  
thing" for your libs. That being said I do NOT warranty them against  
bugs. If you find a bug let me know. I'll do what I can to fix them.

I am compiling on OS X 10.4.11 (Intel and PPC). The scripts seem to  
work for my setup.

Also, if you have control over how all your support libs are compiled  
you can always compile them as static and avoid these problems.

Hope that answers your questions.
Mike Jackson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20071204/2ff144b1/attachment-0001.htm