[CMake] SET_TARGET_PROPERTIES question on MacOSX

Félix C. Morency felix.morency at gmail.com
Wed Dec 5 12:50:34 EST 2007


Mike,

Thank again for your answers. I checked your tool and it seems to work great
here. I will add some more features (QT4 sublibs) to it and send you the
patch asap.

I will follow your advices and concentrate my efforts on making my bundle
"the good way".

Regards,
Félix C. Morency

On Dec 4, 2007 5:02 PM, Mike Jackson <imikejackson at gmail.com> wrote:

>
> 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/20071205/73e73a31/attachment.html


More information about the CMake mailing list