Re: non-flattened filesystem layout

[Stefan Bidigaray]

On Jun 25, 2016 3:49 AM, "Richard Frith-Macdonald" <address@hidden> 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.
>

I just built all of gnustep last night! I guess I can go back and do it all again. Haha

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

I'm not sure I see there advantage of keeping the obj/ directory, or in this case, symlink. Won't it cause some confusion as folks try to figure out to which architecture it points to if they built a few in a row? For example, if I have a script that builds both 686 and amd64 binaries, when I'm done, I'm going to have to run ls -lh to figure out where obj/ is pointing to, anyway.

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

I'm all for that. I think the latest statistics point to most folks moving to Windows 7, now.

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

Why not use the --host and --build configure directives? This is what they are there for and takes the guess work out. It also allows us to pick the right compiler (triple-gcc, for example).

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

I do have some thoughts here, but I'll wait a little while because I think this will mean a bit of an overhaul to the lookup system.

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

Personally, I think we should be taking responsibilities away from make, not adding more to it, but I digress.

I don't think we should mandate a particular directory for anything. At the same time, I'm not sure how gnustep make currently does things (is just a black box, from my point of view) so I don't think I can give any meaningful opinion.

>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev