gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-flattened filesystem layout


From: Richard Frith-Macdonald
Subject: Re: non-flattened filesystem layout
Date: Thu, 30 Jun 2016 08:55:05 +0100

> On 30 Jun 2016, at 00:23, Stefan Bidigaray <address@hidden> wrote:
> 
> OK, I've had a chance to play around with this over the last few days and 
> have, probably, more comments that you care for. I organized this email by 
> general comments and details about them...
> 
> GUESSING THE ARCH TRIPLET
> So I installed with --disable-nonflattened and ended up with a 
> ix86-pc-linux-gnu/ directory in /usr/lib. Even if we were to standardize this 
> to i386-pc-linux-gnu, it would still be different to what Debian is offering 
> (see https://wiki.debian.org/Multiarch/Tuples). There, the "vendor" section 
> of the tuple is missing. According to the Autoconf manual, if --build, --host 
> and/or --target are to be used (with AC_CANONICAL_{BUILD,HOST,TARGET}), then 
> a current config.guess must be included.

I agree completely ...I already highlighted this as the next stage we need to 
sort out.  As yet I havent managed to find out exactly how Debian does this.

> LIBRARY COMBOS
> I don't understand why these are still needed. Can't the library combo be 
> inferred from the architecture triplet, nowadays? Maybe this was something 
> that made sense when GNUstep first started, as there were so many completing 
> ObjC libraries? Currently, I'm not entirely convinced this makes sense. For 
> example, if you are deploying for apple-apple-apple your arch-triplet is 
> x86_64-apple-darwin (or is it x86_64-apple-apple? I don't know), right? Is 
> anything besides gnu-gnu-gnu and apple-apple-apple still around? As far as I 
> can tell, adding this directory makes our non-flattened system incompatible 
> with the Debian multi-arch system. And honestly, I'm not sure it is still 
> buying us anything of value. It should be up to the person compiling GNUstep 
> to ensure that they are not mixing the GNUstep libraries and something else 
> that might be compatible. I mean, this person should know.

I almost agree ... in fact there are few real libraries combos, and it never 
been the case afaik that the gui part was necessary, but ...
I have gnu-gnu-gnu and ng-gnu-gnu and apple-apple-apple, and there are a couple 
of others people are probably still using.
The library combo doesn't break Debian compatibility at all, because it's a 
separete subdirectory;
ie we have path/architecture/combo/resources not 
path/architecture-combo/resources and as far as debina is concerned 
combo/resources can be seen as equivalent to just resources
So while I'm not convice the library combo is ideal, I also don't see it as a 
problem (and do see a need for it, or something equivalent, to exist for the 
forseeable future). 


> HOST/TARGET NOMENCLATURE CONFUSION
> My first problem while reading through the current GNUstep-make documentation 
> was with contradictory nomenclature between Autotools and GNUstep-make. In 
> Autotools parlance, build is the machine where to software is being build, 
> host is the machine where the software will be run, and target is the machine 
> where the output of the software will be run on (only really applies to 
> compilers, I think). This means that there's a constant translation that 
> needs to happen in your head, where: Autotools build -> GNUstep-make host; 
> Autotools host -> GNUstep-make target; and Autotools target -> ??? 
> (https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html#Specifying-Target-Triplets).
>  When I started looking over our documentation earlier this week, I was 
> utterly confused by section 1.7.3 of the make documentation 
> (http://www.gnustep.org/resources/documentation/make_1.html). It took me a 
> few minutes to realize the GNUstep nomenclature was inconsistent with 
> Autotools. I, personally, consider this to be a major bug in GNUstep.

Agreed, I have beeen confused by this too.  In fairness to the original author 
of the code, the GNUstep terminology makes much more sense (and was probably 
implemented in ignorance of autotools cross-compilation), but 
compatibility/consistency withg autotools seems more important to me.

> DEFAULT TO NON-FLATTENED
> Riccardo makes a good point, and maybe it would not make it any easier to 
> default to the non-flattened. People who need this layout are already going 
> to be intimate with the GNUstep build system (a distribution maintainer) and 
> will know to add --disable-nonflattened to GNUstep-make.

I shouldn't have brought this up ... it's very much the last thing to look at 
if/when we are satisfied with multiarch support in general.

>  (3) include a current config.guess script (we can probably steal one from 
> the GCC or Glibc project)
Yep, but Debian docs say they use a 'sanitised' version ... so we also need to 
figure out how to do that.

>  (4) fix GNUstep's use of build, host and target (GNUSTEP_BUILD and 
> GNUSTEP_HOST, GNUSTEP_TARGET should go away);
I guess so, though I think this is something we could do after getting other 
things working.

> (5) if GNUstep-make's configure script is given a --target=cpu-vendor-os 
> directive, that indicates all packages using it are to be installed in a 
> non-flattened manner to that target and define GNUSTEP_HOST to this value;
I thought that aleready applied (or something similar).

> (6) introduce a --enable-unbundled and use the values of Autoconf's 
> installation directory variables 
> (https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables)
>  to figure out where "unbundled" installations go 
We already have filesystem layout info which works with the Cocoa APIs so that 
apps can find installed resources at runtime, and we need to keep that 
capability.
But perhaps we could add an option to check that the autoconf filesystem, info 
is consistent with the current selected filesystem layout.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]