Re: [Fink-devel] qtiplot - an example of 'flag-sort'
Jean-François Mertens wrote: > >> On 25 Jun 2009, at 22:27, Daniel Macks wrote: >> >> ln ../c++ ../cc > > Sorry to have been offline.. > Thanks AKH ! > >>> If this idiom is popular, would be easy enough to add a pile of cc and >>> c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. > > Might be convenient, right, as a last recourse.. (when neither > fixing the buildsystem itself to generate a correct ordering > nor using SetCC and SetCXX to set the compilers to "flag-sort yourself" > seem practicable). > But some fix would be needed in the logic of the script to ensure > proper working of e.g. ccache-default when installed. > > JF > In this case it also solved /sw vs /usr/X11(R6) flag ordering too. We probably should pick whatever solution seems the least fragile. -- Alexander Hansen Fink User Liaison -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink wine package, Tiger and Wine?
Damian Dimmich wrote: > Hey Joerg, > >>> HTH, let me know if you hit any issues with the packages. >>> >>> >> So far I've installed neither Fink nor MacPorts, as I thought the first was >> outdated and the second seems to do everything, even compilation as root, >> which I find unacceptable. I merely looked at both online package >> descriptions. >> >> > IIrc compilation is done in a fakeroot environment on Fink (don't quote > me - you'd best ask on fink-devel for that: fink-de...@lists.sf.net). > Fink compiles/creates a deb file which you can then install. This means > you don't have to install the dev packages, and/or can remove them. > Our compiles aren't done under a fakeroot either (i believe that historically it wasn't possible on OS X at all).The compilation occurs within fink's restricted directory tree, though. One can use what we call "--build-as-nobody" mode, which builds the package as an underprivileged user. This is useful during testing to detect instances in which the install process tries to put stuff directly into the filesystem, rather than in the directory tree that is used to create the .deb file. Apparently some packages don't build correctly when done this way (as opposed to failing, which can also happen), but it seems like those that I've tried (I validate packages from the submissions tracker, and do some runtime testing on new user-executable ones) don't have any problems with that. All installations, though, _must_ be done as root, because Debian's tools insist on it, and my understanding is that they're not particularly easy to patch. -- Alexander Hansen Fink User Liaison -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink wine package, Tiger and Wine?
Hey Joerg, >> HTH, let me know if you hit any issues with the packages. >> > So far I've installed neither Fink nor MacPorts, as I thought the first was > outdated and the second seems to do everything, even compilation as root, > which I find unacceptable. I merely looked at both online package > descriptions. > IIrc compilation is done in a fakeroot environment on Fink (don't quote me - you'd best ask on fink-devel for that: fink-de...@lists.sf.net). Fink compiles/creates a deb file which you can then install. This means you don't have to install the dev packages, and/or can remove them. > As far as Wine is concerned, I wanted to see how far I could go with Apple > only tools. On Leopard, only the XCode install DVD I got with the machine and > XQuartz are needed to build a working Wine. (I also submitted some patches). > That sounds about right, although up until recently this was not the case. > However, I'm in need of a package management system, as e.g. I haven't even > installed git on the Mac. > This is why I use fink :). Self-compilation becomes tedious very quickly. Fink permits you to create new packages or maintain existing ones quite easily. For updated wine versions, I usually just update the version number in a packages config file, and run fink install wine. > What I see from the package description of both systems is that the build > dependencies look really huge. I got the impression that Fink and MacPorts > build a second system from OSS only in parallel to Apple's libraries. > The deps are quite big, but, for most things there are virtual packages that can satisfy the dependencies using xcode/etc. Fink does require xcode and uses xcodes's gcc, although you can also install your own. Similarly X has virtual packages and so do many other tools and libraries. The core isn't too big, mostly its dpkg, tar and some other gnu libraries that aren't compatible with apples. > Well, I should probably write this stuff to an appropriate Fink mailing list > rather than private e-mail. Feel free to forward or add CC. > CC'ed to the list. > A) large Wine dependencies > I know that wine's configure complains about lack of dbus & hal, but do these > libraries make sense on a MacOS system? I believe MacOS has its own > notification system. So from the little I know, there's no value to depend > on and include these libraries. > > arts, esound, jack ... I know it's nice to have a fully populated winecfg > audio tab, but is that really useful? On the MacOS, I go with CoreAudio and > that's all (I'm no music expert). > > Perhaps the lack of binary distributions makes this matter worse. On Ubuntu > or Suse, a run-time dependency on foo-dev means a download of 100KB. On Fink > and MacPorts, it means producing the -dev package, which means download and > compile of the complete source and their dependencies. For mesa/Xorg, that > makes quite a difference! > > For comparison, I got a working Wine (without lcms and a few others) on > Leopard with nothing but Xcode and XQuartz, whereas Fink and MacPorts make it > look like a job of several hundred megabyte of downloads, compilation and > disk space usage. > It may make sense to get rid of these dependencies on osx, however that would mean that if someone wanted to use arts/esound etc they would have to build stuff themselves. As far as I can see most package management systems have to make some sort of compromise on functionality/dependencies. > B) Duplicating programs and libraries available from Apple via Xcode > Reading just the online package descriptions, I could not see how many 'meta' > or 'virtual' packages there are for the SW that may come from Apple, e.g. > gcc-4.0, gcc-4.2, make, autoconf, flex, Xorg/XQuartz, openssl ... > I would try to avoid duplicating all that. A collection of pseudo-package > seems a nice way to solve this. It would be the user's choice to "install" > them. > OTOH, I can understand that packagers prefer to rely on the up to date online > OSS packages, because e.g. Apple's autoconf may be as old a Tiger 10.4.0 on > the user's machine, while it's 2009 now. IIRC the Fink or MacPorts FAQ > mentions this reason. > Fink gives you this option for many packages - allowing you to chose between a virtual package and the real one. > 17 years ago on SunOS, I myself built a parallel hierarchy of OSS programs in > a directory distinct from /bin/ and /usr/bin, with some annoyances (e.g. > known incompatibilities between Sun tar and GNU tar). > Fink also keeps its own GNU tar :). > IMHO, the best would be a collection of "fake" packages for Apple/Xcode > provided programs, probably with low version numbers, then see how far one > can get. ... May cost a lot of time and cause headaches to test and maintain > compatibility. If you're interested in Fink, you'd probably best get in touch with the developers and have a chat with them - I don't have enough time to
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
> On 25 Jun 2009, at 22:27, Daniel Macks wrote: > > ln ../c++ ../cc Sorry to have been offline.. Thanks AKH ! >> If this idiom is popular, would be easy enough to add a pile of cc >> and >> c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. Might be convenient, right, as a last recourse.. (when neither fixing the buildsystem itself to generate a correct ordering nor using SetCC and SetCXX to set the compilers to "flag-sort yourself" seem practicable). But some fix would be needed in the logic of the script to ensure proper working of e.g. ccache-default when installed. JF -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
On Fri, Jun 26, 2009 at 09:27:36AM +0200, Alexander Hansen wrote: > Daniel Macks wrote: > > On Thu, Jun 25, 2009 at 08:27:10PM +0200, Alexander Hansen wrote: > >> Jean-Fran?ois Mertens wrote: > ln ../c++ ../cc > > > > > I *think* that last line should be "ln c++ ../cc" (otherwise ../cc > > points to ../../c++), but otherwise seems fine. > > > > > This is a hard link, though; so I wouldn't think the paths should > matter, since 'c++' doesn't _point_ to 'cc' but rather is a _copy of_ > 'cc'. At least that's how it worked when I was playing around with it. Ah yeah, I totally read a -s in there. Hardlink does indeed Do The Right Thing for the original syntax. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
Alexander Hansen wrote: > (adding jfm back) > > Daniel Macks wrote: > >> On Thu, Jun 25, 2009 at 08:27:10PM +0200, Alexander Hansen wrote: >> >> >>> Jean-Fran?ois Mertens wrote: >>> >>> Too lazy to try fixing this cmake stuff.. (sure there must be a way, either to fix the flag-ordering, or to change compiler and linker); so, dirty solution : Adding to the patchscript the lines > echo '#!/bin/sh -ev > name=`basename $0` > flag-sort -v /usr/bin/$name $@' >> ../c++ > chmod a+x ../c++ > ln ../c++ ../cc > > >> I *think* that last line should be "ln c++ ../cc" (otherwise ../cc >> points to ../../c++), but otherwise seems fine. >> >> >> > This is a hard link, though; so I wouldn't think the paths should > matter, since 'c++' doesn't _point_ to 'cc' but rather is a _copy of_ > 'cc'. At least that's how it worked when I was playing around with it. > and changing the PATH line to : > export PATH="%b/..:$QTDIR/bin:%p/lib/freetype219/bin:$PATH" > > >> If this idiom is popular, would be easy enough to add a pile of cc and >> c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. >> >> Unrelatedly, if your BDep:freetype219 is >= 2.3.7-7, you do not need >> special PATH (or any other) flags or variables to find ft219. And if >> you are Dep/BDep >= 2.3.8-2, you also avoid some freetype219 >> backwards-incompatible ABI breakage. >> >> dan >> >> >> > I'm not sure if the freetype219 path is even needed here. The package > doesn't carry a direct dependency on freetype219 (and doesn't link to it). > > belay that. It finds X11's freetype2 by default. -- Alexander Hansen Fink User Liaison -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
(adding jfm back) Daniel Macks wrote: > On Thu, Jun 25, 2009 at 08:27:10PM +0200, Alexander Hansen wrote: > >> Jean-Fran?ois Mertens wrote: >> >>> Too lazy to try fixing this cmake stuff.. (sure there must be a way, >>> either to fix >>> the flag-ordering, or to change compiler and linker); so, dirty >>> solution : >>> Adding to the patchscript the lines >>> >>> echo '#!/bin/sh -ev name=`basename $0` flag-sort -v /usr/bin/$name $@' >> ../c++ chmod a+x ../c++ ln ../c++ ../cc > > I *think* that last line should be "ln c++ ../cc" (otherwise ../cc > points to ../../c++), but otherwise seems fine. > > This is a hard link, though; so I wouldn't think the paths should matter, since 'c++' doesn't _point_ to 'cc' but rather is a _copy of_ 'cc'. At least that's how it worked when I was playing around with it. >>> and changing the PATH line to : >>> >>> export PATH="%b/..:$QTDIR/bin:%p/lib/freetype219/bin:$PATH" > > If this idiom is popular, would be easy enough to add a pile of cc and > c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. > > Unrelatedly, if your BDep:freetype219 is >= 2.3.7-7, you do not need > special PATH (or any other) flags or variables to find ft219. And if > you are Dep/BDep >= 2.3.8-2, you also avoid some freetype219 > backwards-incompatible ABI breakage. > > dan > > I'm not sure if the freetype219 path is even needed here. The package doesn't carry a direct dependency on freetype219 (and doesn't link to it). -- Alexander Hansen Fink User Liaison -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
