Re: [Fink-devel] openmpi and case-sensitive HFS

2009-06-20 Thread Jack Howarth
That would still be hacking around the problem. We have to face the fact that MacOS X supports both a case-sensitive and case-insensitive file system. This means we should have some mechanism to allow for a Files list with foobar on case-insensitive and foobar/fooBar on case sensitive. On Sat, Jun

Re: [Fink-devel] making qt4 variants

2009-06-20 Thread Koen van der Drift
On Jun 19, 2009, at 3:57 PM, Alexander Hansen wrote: > For 3), if there's file overlap, and you want to get rid of the qt3 > version, you may want to make a dummy upgrade package for the older > kemboss that Depends on the appropriate Variant(s) of kemboss-qt4; > e.g. > if it only overlaps with

Re: [Fink-devel] openmpi and case-sensitive HFS

2009-06-20 Thread monipol
On 20/06/2009, at 18:48, Jack Howarth wrote: > I have been looking at adjusting the openmpi > package to allow it to build and install on > case-sensitive HFS filesystems. I am stuck on > how to properly steer mpiCC into the openmpi-dev > Files list without breaking the build on the > standard HF

[Fink-devel] openmpi and case-sensitive HFS

2009-06-20 Thread Jack Howarth
I have been looking at adjusting the openmpi package to allow it to build and install on case-sensitive HFS filesystems. I am stuck on how to properly steer mpiCC into the openmpi-dev Files list without breaking the build on the standard HFS filesystem. Perhaps we need some way of flagging files

Re: [Fink-devel] making qt4 variants

2009-06-20 Thread Koen van der Drift
On Jun 20, 2009, at 2:23 PM, Benjamin Reed wrote: > No, building against qt4-mac should give you aqua-native apps (well, > technically it's using Carbon). It should not start X11. If it does, > something went wrong with your build. Yes it did - I was using the wrong qmake. I fixed that and now

Re: [Fink-devel] making qt4 variants

2009-06-20 Thread Benjamin Reed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/20/09 10:18 AM, Koen van der Drift wrote: > > Thanks both for your answers. > > I build both versions, and they just look the same. I guess I was > confused by thinking that qt4-mac would make it look like a aqua app. > It's still an X11 ba

Re: [Fink-devel] /usr/lib/libiconv in Fink's .la files

2009-06-20 Thread Alexander Hansen
Monic Polynomial wrote: > Hiya, > > I've noticed that a bunch of .la files in /sw/lib specify /usr/lib/ > libiconv.la in their dependency_libs entry. Is it expected behaviour > (maybe because of inheritance from libXft.la, libcairo.la, > libfontconfig.la in /usr/X11/lib) or should they be usin

Re: [Fink-devel] making qt4 variants

2009-06-20 Thread Alexander Hansen
Koen van der Drift wrote: > > Thanks both for your answers. > > I build both versions, and they just look the same. I guess I was > confused by thinking that qt4-mac would make it look like a aqua app. > It's still an X11 based app, and will appear in an X11 window. So for > now I will just leave

Re: [Fink-devel] making qt4 variants

2009-06-20 Thread Koen van der Drift
Thanks both for your answers. I build both versions, and they just look the same. I guess I was confused by thinking that qt4-mac would make it look like a aqua app. It's still an X11 based app, and will appear in an X11 window. So for now I will just leave the current kemboss.info package

Re: [Fink-devel] X11/lib/*.la files are back!

2009-06-20 Thread Alexander Hansen
Martin Costabel wrote: > In the new Xcode-3.1.3, Apple made the *.la files in /usr/X11/lib > reappear. At a first glance, it looks like they did it right: The > "library_names" line now only contains the install_name and the > version-less name, the latter being guaranteed to be present at compi

[Fink-devel] X11/lib/*.la files are back!

2009-06-20 Thread Martin Costabel
In the new Xcode-3.1.3, Apple made the *.la files in /usr/X11/lib reappear. At a first glance, it looks like they did it right: The "library_names" line now only contains the install_name and the version-less name, the latter being guaranteed to be present at compile time. So there should be no