Hello,
I would like to share my experience packaging XSB for the Guix package manager, with the aim of revealing any bugs that I may have encountered during the process as well as provide an example package for those who would like to package XSB in other formats.
This report covers potentially more than one bug, so if desirable I can break this up into multiple bug reports instead.
Most notably:
The newerthan syspath_op
evaluates to true when the modification timestamps of two files are equal. I'm not sure if this is a bug or not, but its use for checking if files need recompiling is an issue particularly for Guix because builds are put in a read-only store where file timestamps are reset to Unix epoch for reproducibility purposes. This means that when these timestamps are set on build completion, XSB will attempt to rebuild again in a read-only environment and crash. I was able to resolve this by patching needs_recompile(newerthan,PFileName,Obj)
in syslib/consult.P
to not include cases where they are equal, though (see attached).
It also appears that the build option for./configure
may not be working. Guix on my system automatically provides --build=x86_64-unknown-linux-gnu
, but it seems that ./makexsb
ignores this and uses the default x86_64-pc-linux-gnu
as if no build option was provided, thus causing files to not be found.
Please feel free to examine the attached package definition for further analysis. This package may still have quirks that I need to sort out, but it is currently in a usable state for me, and I do plan on submitting it to be included in the official repositories once I feel that I have satisfied the packaging guidelines.
I would be happy to provide any further information or assistance.
Hi, Alwin, sorry for the long wait.
There probably are as many arguments for as there are against recompiling xwam with modtime equal to that of its corresponding .P file.
Perhaps a global flag could be used to indicate that.
As to the --build option, it is not supported.
--
--- michael
Hello Michael,
Admittedly, I think this bug report was a bit premature given my experience, and
I should have taken some more time with it - apologies for that. I'm still
interested in working on getting this upstream, but I'll likely need to look
over this and work more closely with the Guix maintainers to see if some of
these issues should/can be taken care of on the packaging side.
Hopefully I can get back soon on this; for now, perhaps it might be useful for
others looking to package XSB for other formats :)
Thanks for looking into this.
Hello again,
I finally got around to bringing the modtime recompilation issue up with others in the Guix community, and it seems like resolving it without a downstream patch would indeed require a change in how XSB decides when recompilation is needed.
Would a build-time flag for determining this be acceptable? An environment variable check might also work (we can wrap
xsb
to always have it set in this case).I see that David changed<= to <.
Will use it for now unless someone complains that this breaks something
Feb 8, 2024 23:27:09 Alvin Hsu alvhsu@users.sourceforge.net:
Related
Bugs: #259
Hi Michael,
Thanks for going through with this! Unfortunately, it appears that the issue is still present at commit [660f0f79b1007f2f0be5bfa4e079abaf12b4f1d9]; building without my patch results in XSB attempting to recompile for equal modtimes as it did before.
I've written a shell script that reproduces this on my end with a standard (non-Guix) build that follows "Installing XSB under UNIX" in the manual:
Here is XSB's output for that last invocation in the script:
I've also attached the patch I previously used to mitigate this issue which still works.
Related
Commit: [660f0f]
Why do you touch xsb configuration.p?
You can see that this causes an error.
Try touching a new empty file
Feb 13, 2024 02:44:27 Alvin Hsu alvhsu@users.sourceforge.net:
Related
Bugs: #259
Commit: [660f0f]
Hi Michael,
The
touch
commands were meant to emulate an XSB source file having the same modtime as its compiled file. This issue is not unique toxsb_configuration.P
; I just used it as an example. Guix sets all file modtimes to the UNIX epoch and installs packages in read-only directories for reproducibility purposes, so this issue should show up with any built-in recompile-able module.I see I didn't change all the places that file times were checked. I've found and changed more. I will see if it passes the testsuite, and if so, commit the changes. Stay tuned....
I've committed the changes. Alvin, can you try again?
Hi David,
It looks like XSB still encounters the same error. The offender seems to be the use of
path_sysop/3
on line 227 ofconsult.P
in this case; I've attached a patch that swaps it out forfile_strictly_older_than/2
which allows me to start the REPL without an error.You found another way file times are tested.
OK. I've made changes to the system, as you suggested. Maybe now we've found them all?
Thanks for your patience.
I believe I may have found one more case.
Recompilation is triggered for at least a subset of packages in
$XSB_DIR/packages
. I can get it to reliably reproduce with the following shell script on a fresh build of git-origin (using[wildmatch]
as an example, although brief testing of[regmatch]
shows the same result):This appears to be triggered when
config/x86_64-pc-linux-gnu/lib/xsb_wildmatch.xwam
andpackages/wildmatch/cc/xsb_wildmatch.c
have equal timestamps. Unfortunately no patch/trace at the moment.I have been unable to find any other cases so far, although my testing may not be exhaustive.
I may have found what's wrong with this package. Please try