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 <[EMAIL PROTECTED]> 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 >
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
