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" <r...@gnu.org> wrote: > > > On 30 Jun 2016, at 00:23, Stefan Bidigaray <stefanb...@gmail.com> 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. > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
