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. 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. 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. 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. Maybe, a solution is to (1) continue installing to the non-flattened layout by default; (2) get rid the library-combo directory (I'm assuming this is a no longer needed); (3) include a current config.guess script (we can probably steal one from the GCC or Glibc project) and use it if --disable-nonflattened is ever defined; (4) fix GNUstep's use of build, host and target (GNUSTEP_BUILD and GNUSTEP_HOST, GNUSTEP_TARGET should go away); (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; (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 (I guess some new make options would be needed to differentiate between arch-dependent and arch-independent resources, as you mentioned). Hopefully this all makes sense. I apologize for how long it came out, but it's a complicated issue and GNUstep has a lot of baggage from being around for 20+ years. Regards Stefan On Sat, Jun 25, 2016 at 3:49 AM, Richard Frith-Macdonald <r...@gnu.org> wrote: > I finally got round to committing the changes to the non-flattened > directory layout that I emailed about a few weeks ago. > > The move to seamless Debian multi-arch compatibility is very much a work > in progress, but even so I'd be grateful if people who habitually hack on > gnustep would switch to using the non-flattened layout and provide bug > reports. > > Many years ago, the non-flattened layout was the only option, but we moved > away from it because we thought the added complexity was discouraging > people from using GNUstep. That was probably true, but now that 64bit > machines are commonplace, its a lot more usual to see different library > directories etc, and maybe we could aim to switch the default back to > non-flattened at some point. > > If we do, then we will want to make things easier than they used to be: > When flattened mode was introduced, for a flattened build we started > putting uninstalled binaries in a 'obj' subdirectory, instead of the > cpu/os/library-combo subdirectory. > I think we should maintain that convenience by still having 'obj' on a > non-flattened build, but making it a symbolic link to the actual > architecture subdirectory, and having it removed and recreated on every > invocation of make,. so that it always refers to the most recently built > binaries. That way, when we've just built foo, we know we can debug it > with 'gdb obj/foo' etc. > > But symbolic links don't work on windows XP (except NTFS with an add-on > tool apparently) or FAT filesystems at all. Could we drop support for XP > and for building/installing on the old filesystem? Or would we want to do > something like copy all the binaries? > > Apart from the 'obj' subdirectory issue, I see two remaining issues; > > One relatively minor one, would be to figure out how to ensure that our > sanitised cpu-os-abi triples are the same as debian ones ... maybe they > already are for common platforms, but we need to check and figure out the > best way to make sure they are kept in sync. > > The major one is 'unbundling' for installation in the Debian > interpretation of FHS. > > The GNUstep/Cocoa/OpenStep APIs are built around installation of bundles > where everything for an app/framework/bundle is collected in one directory > hierarchy; > eg. > fhs-path-to-apps/foo.app/architecture/library-combo/binary > fhs-path-to-apps/foo.app/Resources/architecture-independent > > The Debian FHS installation expects something more like this (rough idea); > > fhs-path-to-apps/architecture/foo.app/library-combo/binary > hfs-path-to-arch-independent/foo.app/Resources/architecture-independent > > NB. actually I read that the current Debian multi-arch doesn't handle > executables yet (though they might in future) .. but this already applies > to bundles and frameworks. > > That means we need a way to do an unbundled install which will move the > 'architecture' part of the whole path, breaking up the bundle into separate > parts of the filesystem, rather than simply unpacking the bundle into a > directory. > The uninstall would have to remove from separate parts of the filesystem, > rather than simply removing the bundle directory. > At runtime, the implementation of the path utility APIa and bundle APIs > for accessing resources would need to somehow transparently retrieve > resources from the different palaces they are installed. > > We may also need a few new options in gnustep-make to more clearly > differentiate between types of resources. On the other hand, perhaps we > can just put architecture dependent resources in an appropriate > subdirectory in the source tree and build in some intelligence to > gnustep-make to have it understand what they are and how they should be > installed. > > > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
