Re: non-flattened filesystem layout

[Stefan Bidigaray]

FYI... apparently I still had old headers on my system when I tested this all out... cleaned everything up and tried again and GSConfig.h gets installed to the wrong place. Only that header goes to /usr/include/ix86-linux-gnu/gnu-gnu-gnu/ix86-linux-gnu/gnu-gnu-gnu/. This seems to stem from the fact that configure takes Headers/GNUstepBase/GSConfig.h.in and outputs it to Sources/ix86-linux-gnu/gnu-gnu-gnu/GSCinfig.h, which is a strange place for it to go (from Headers to Sources).

That's the only header that gets installed to the wrong place, as far as i can tell. Because of this, I can't build anything depending on base, it all falls because GSConfig.h isn't found.

Regards
Stefan

On Jun 30, 2016 3:55 AM, "Richard Frith-Macdonald" <address@hidden> wrote:

> 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.