On 8/23/10 3:21 PM, Kees Bakker wrote:
> On 23 Aug, 2010, at 20:00 , Martin Costabel wrote:
>
>> Kees Bakker wrote:
>>> Hi,
>>> The cmake installation in Fink changes the default for CMAKE_FIND_FRAMEWORK
>>> from "First" into "Last".
>>> This was a bad idea. Can we revert that change, please?
>>> I have the following reasons to ask for this revert.
>>> 1. The documentation of cmake (in the Fink installation and on the Internet)
>>> says that the default is "First".
>>> 2. Using the Fink cmake is very confusing if you don't know that the default
>>> was changed to "Last". (Hell, cmake by itself is already a monster, let
>>> alone
>>> if you run into something like this.)
>>> 3. The behaviour of FIND_PATH for "First" and "Last" is not the same. Trying
>>> to avoid wasted CPU cycles is good, but not if the behaviour of cmake is
>>> changed.
>>> 4. The cmake installation DMG from www.cmake.org has the default set to
>>> "First".
>>
>> Do you have a concrete example where the value "LAST" for
>> CMAKE_FIND_FRAMEWORK leads to serious trouble?
>
> Yes, I have a program that I want to link against my own copy
> of the SDL framework. It doesn't really matter where I put it,
> it keeps finding the SDL library in /sw
>
> Have a look at FindSDL.cmake where it lists:
> FIND_PATH(SDL_INCLUDE_DIR SDL.h
> HINTS
> $ENV{SDLDIR}
> PATH_SUFFIXES include/SDL include
> PATHS
> ~/Library/Frameworks
> /Library/Frameworks
> /usr/local/include/SDL12
> /usr/local/include/SDL11 # FreeBSD ports
> /usr/include/SDL12
> /usr/include/SDL11
> /sw # Fink
> /opt/local # DarwinPorts
> /opt/csw # Blastwave
> /opt
> )
>
> So, a programmer like we won't understand why the framework in
> ~/Library/Frameworks is not found.
>
> It took me several hours to figure out why the cmake documentation
> wasn't matching its behaviour. Finally I decided to build cmake
> from scratch (outside Fink) to discover that this one worked as
> documented.
>
>>
>> I am sorry, but none of your points convinces me that "this was a bad
>> idea". I concede that there is a lack of documentation, and I will look
>> at this. But without a concrete example where it is harmful I don't
>> see any reason to change this setting.
>>
>> I have been struggling to get cmake well-behaved in the Fink
>> environment for many years, long before cmake was even aware of the
>> existence of frameworks. I do not want to go back to a situation
>> where the 3rd party random junk that is typically installed in
>> /Library/Frameworks/ interferes with building Fink packages.
>
> Hmmm. I see the problem.
>
>> Currently there are around 260 Fink packages (not counting variants and
>> splitoffs) that use the cmake build system, with the current default of
>> CMAKE_FIND_FRAMEWORK that has been set to LAST since 2 years. Without a
>> good reason, I do not want to risk breaking any of these packages.
>
>
> The problem really is that there are two uses of cmake. One is to
> build Fink packages which must totally rely on the Fink environment.
> For this there may be a valid point to change the default. But perhaps
> it would have been better to set it to NEVER.
>
> And the other use is outside the Fink package building environment. In
> this case you want CMAKE_FIND_FRAMEWORK to be FIRST.
>
> I sympathize with your struggle with cmake. I've said it before, it's
> a monster. There are way too few methods to diagnose why cmake is doing
> that it is doing. And the documentation, albeit massive, still is hard
> to understand or oversee.
>
> I still believe that it was wrong to change the default, but at the same
> time I must admit that I don't know how to properly build Fink packages
> and guarantee that only the Fink environment will be used.
>
> For now my problem is solved by setting CMAKE_FIND_FRAMEWORK back to FIRST
> at the top level CMakeLists.txt. And hopefully this discussion here will
> be picked by Google when someone else runs into this problem too.
>
> Kind regards,
> Kees Bakker
>
> PS and BTW. If the Fink packages were build as "fat binaries" for i386 and ppc
> I would never have tried to use my own framework.
>
>
Changing our internal documentation for our cmake would be a good idea
to let people know what to expect. This could include a usage note in
the package description concerning CMAKE_FIND_FRAMEWORK.
Also, you may find that you'd like to have a local version of cmake with
the options set as you like so that you don't have to worry about
editing CMakeLists.txt all the time. I'll point you to
http://finkers.wordpress.com/2009/06/08/local-packages/
One option you might find useful would be to make up a separate package
("cmake-mine", maybe) which is set up with CMAKE_FIND_FRAMEWORK=FIRST,
and which Conflicts/Replaces cmake, and vice versa. That way Fink can
install a version which is compatible with its package builds, when
needed, and you can swap that out and install "cmake-mine" for your own
builds.
--
Alexander Hansen
Fink User Liaison
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
