Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
Kees Bakker wrote: On 23 Aug, 2010, at 20:00 , Martin Costabel wrote: [] 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 I did some testing: Installing a SDL.framework in /Library/Frameworks(*) and a cmake package that has CMAKE_FIND_FRAMEWORK=FIRST, I tried to build at random one of Fink's game packages that use sdl, violetland-0.2.10-1002. It failed on linking the executable, with some undefined symbols. Without trying to go to the bottom of the failure, I strongly suspect that the reason is that it finds a mixture of the sdl framework with some other sdl parts from Fink: costabel% grep -i sdl /sw/src/fink.build/violetland-0.2.10-1002/violetland-v0.2.10/CMakeCache.txt SDLIMAGE_INCLUDE_DIR:PATH=/sw/include/SDL SDLIMAGE_LIBRARY:FILEPATH=/sw/lib/libSDL_image.dylib SDLMIXER_INCLUDE_DIR:PATH=/sw/include/SDL SDLMIXER_LIBRARY:FILEPATH=/sw/lib/libSDL_mixer.dylib SDLTTF_INCLUDE_DIR:PATH=/sw/include/SDL SDLTTF_LIBRARY:FILEPATH=/sw/lib/libSDL_ttf.dylib SDL_INCLUDE_DIR:PATH=/Library/Frameworks/SDL.framework/Headers //Where the SDL Library can be found SDL_LIBRARY:STRING=/Library/Frameworks/SDL.framework;-framework Cocoa SDL_LIBRARY_TEMP:INTERNAL=/Library/Frameworks/SDL.framework;-framework Cocoa With the cmake package that has CMAKE_FIND_FRAMEWORK=LAST, it builds without any problem. I suspect the same problems will arise with other Fink packages. Thus the question is whether we want to protect all cmake-using Fink packages individually against stuff that might or might not be installed in /Library/Frameworks (and system stuff in /System/Library/Frameworks that we might not want to link against) or have a slightly non-standard default that does this protection globally. In your case, I suppose setting some cmake flags, like SDL_INCLUDE_DIR and SDL_LIBRARY, to point to the framework in ~/Library/Frameworks should do the trick. (*) Placing the framework in ~/Library/Frameworks does not expose it to cmake during Fink builds, because then the $HOME environment variable is set differently, so ~ does not expand to /Users/costabel, but to something like /var/folders/I5/I5XYEUYz2RWfpk+8ZKtEUTI/-Tmp-/fink-build-HOME.gm9A4gNcfa -- Martin -- 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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
On Tuesday 24 August 2010, David R. Morrison wrote: On Aug 23, 2010, at 12:21 PM, Kees Bakker wrote: 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. Let me comment about why we don't do this. For a large percentage of open source packages (the figure 80% is bandied about) one could simply run make twice with appropriate options and then lipo all the libs and binaries together. This could obviously be automated by Fink. However, we would have to work hard for the additional 10% or 20% -- lots of special cases there. And this is pretty much an all-or-nothing proposition: either Fink is built with fat binaries and then every Fink compile can correctly assume that all libs it accesses are fat, or not -- otherwise, we would need a mechanism to specify which packages were fat and which weren't, and the dependency checking on that would be horrendous. Had Fink begun after OS X on i386 had been introduced, the story might be different... Of course these days, one can argue in favor of including 4 architectures (i386/x86_64/ppc/ppc64) which might even grow in the future, if open source compiling on Apple's chips for mobile devices ever gets going... -- Dave Thanks David, for this insightful information. I didn't know you can lipo binaries together. I'll investigate that some more. Kind regards, Kees Bakker -- 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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
On Tuesday 24 August 2010, Alexander Hansen wrote:
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.
--
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
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? 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. 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. -- Martin -- 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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
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.
--
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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
On Aug 23, 2010, at 12:21 PM, Kees Bakker wrote: 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. Let me comment about why we don't do this. For a large percentage of open source packages (the figure 80% is bandied about) one could simply run make twice with appropriate options and then lipo all the libs and binaries together. This could obviously be automated by Fink. However, we would have to work hard for the additional 10% or 20% -- lots of special cases there. And this is pretty much an all-or-nothing proposition: either Fink is built with fat binaries and then every Fink compile can correctly assume that all libs it accesses are fat, or not -- otherwise, we would need a mechanism to specify which packages were fat and which weren't, and the dependency checking on that would be horrendous. Had Fink begun after OS X on i386 had been introduced, the story might be different... Of course these days, one can argue in favor of including 4 architectures (i386/x86_64/ppc/ppc64) which might even grow in the future, if open source compiling on Apple's chips for mobile devices ever gets going... -- Dave -- 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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
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
[Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
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. Kind regards, Kees Bakker -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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
Re: [Fink-devel] cmake CMAKE_FIND_FRAMEWORK changed to LAST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/20/10 5:43 PM, 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. Kind regards, Kees Bakker That's for the cmake maintainer to decide upon. (cc'ed) - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxu/UsACgkQB8UpO3rKjQ9G5wCfXOj2C4Ow+euJ0Bj3pDk5udOV OjEAniHs3dUK14nlyYNU6W7CcAjaFGl7 =mdzd -END PGP SIGNATURE- -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ 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
