Make all root paths and package directories absolute paths

[lgoettgens]

As discussed in #5916 (comment).

This currently contains #5927; I'll rebase once that is merged.

The changes for package directories are straightforward. The only possible improvement I see for this case is to add a function that takes a Directory obj and converts its internal path into an absolute path. Instead, I just did this by unwrapping the underlying path string, converting, and re-wrapping it in a Directory.

For root paths, my main motivation to change it already in the kernel was that it was already documented in

gap/src/sysroots.h

Lines 50 to 53 in c5a9c8c

	*F SyGetGapRootPaths() . . . . . . . . . return the list of root directories
	**
	** Returns a plain list containing absolute paths of the root directories as
	** string objects.

that root paths are absolute, but this was not verified / converted before. In particular the changes in sysroots.c would be happy to be improved by comments; I am neither fluent with C nor familiar with the coding style in the gap kernel.

I verified that relative paths both in -l and --packagedirs work as expected (checked via GAPInfo.RootPaths and GAPInfo.PackageDirectories, respectively).
Note however that ./gap -l ";./" will result in one root path being there twice. But since this already happens with `./gap -l ";/absolute/path/to/current/dir/" as well, I see no reason to change it.

cc @ThomasBreuer @fingolfin

[lgoettgens]

Hm, it seems a bit weird to me that this only fails for the GAP.jl jobs with macos. The other GAP.jl jobs are fine, as are the macos jobs of pure GAP...

Any ideas what's going on here?

[ChrisJefferson]

I'll let @fingolfin have an opinion, I'm happy to merge this as I think it gets us closer to everything working, but I'm not sure what exactly is needed to fix GAP.jl on mac os (i can see the problem is with packagemanager, so the bug might well be there, and may need this to fix).

[ChrisJefferson]

Can you try rebasing this on top of the current master, just to see if that clears up the GAP.jl issues?

[lgoettgens]

Can you try rebasing this on top of the current master, just to see if that clears up the GAP.jl issues?

Reopening should create a new tentative merge commit on top of the latest master to run CI on. Let's see what CI does now

[ThomasBreuer]

Note however that ./gap -l ";./" will result in one root path being there twice. But since this already happens with ./gap -l ";/absolute/path/to/current/dir/" as well, I see no reason to change it.

I think this duplication of root directories is not really a problem but it causes unnecessary overhead at runtime when GAP tries to find a file in some root directory. For example, currently also the package directories corresponding to duplicate root directories occur several times, which has the effect that the PackagesInfo entries of packages inside the duplicate root directory occur several times.

I think it would be an improvement to turn GAPInfo.RootPaths into a duplicate free list, but to keep the original value of GAPInfo.KernelInfo.GAP_ROOT_PATHS.
I can create a separate pull request for this change, since it is independent of the changes proposed in the current pull request.

[fingolfin]

Sorry I've been busy with other things. Regarding this and @lgoettgens other recent PR about the perfect groups, let me mention that I have a WIP PR that unifies the two root path lists in the kernel and library -- i.e. they'd be identical.

This is enabled by my recent refactoring of the GAP startup code, which allows me to split the command line argument parsing in the kernel in two stages; the first stage is sufficient to get the arguments which specify settings relevant to the GC. After this the GC can be initialized, and then the command line arguments can be scanned again. In this second round the gaproots are handled. Since the memory manager is now around, I can use GAP lists and strings instead of gnarly C code.

This has many advantages, and also lifts the hard limit of <= 16 GAP roots being supported in the kernel list of GAP roots.

However I just didn't have time to finish it all up, there are some annoying details related to workspaces that need to be ironed out. But I'll try to post at least a draft of it today.

[lgoettgens]

Sorry I've been busy with other things. Regarding this and @lgoettgens other recent PR about the perfect groups, let me mention that I have a WIP PR that unifies the two root path lists in the kernel and library -- i.e. they'd be identical.

This is enabled by my recent refactoring of the GAP startup code, which allows me to split the command line argument parsing in the kernel in two stages; the first stage is sufficient to get the arguments which specify settings relevant to the GC. After this the GC can be initialized, and then the command line arguments can be scanned again. In this second round the gaproots are handled. Since the memory manager is now around, I can use GAP lists and strings instead of gnarly C code.

This has many advantages, and also lifts the hard limit of <= 16 GAP roots being supported in the kernel list of GAP roots.

That sounds like a great idea, and would definitely make this PR a lot simpler and probably render #5938 obsolete.

However I just didn't have time to finish it all up, there are some annoying details related to workspaces that need to be ironed out. But I'll try to post at least a draft of it today.

Gentle reminder to do that :)