Dear Lispers,
is any of you interested in automating application delivery using ASDF? Now that I fixed ASDF's bundle operations and CFFI, the missing piece is the part where the bundled object files are linked against the runtime to produce a self-contained executable.
Is anyone interested in writing it? I have all the pieces (at least for SBCL), but assembling them is not my top priority at the moment.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It's not ignorance that does so much damage; it's knowing so darned much that ain't so. — Josh Billings
is any of you interested in automating application delivery using ASDF? Now that I fixed ASDF's bundle operations and CFFI, the missing piece is the part where the bundled object files are linked against the runtime to produce a self-contained executable.
that^ sounds as if it was possible to generate e.g. an SBCL executable core that also includes the CFFI groveler generated .a or .so files linked into it. is that possible?
a cursory look suggests that it is, but not trivial at all:
https://stackoverflow.com/questions/9449845/how-to-link-object-file-to-execu...
It's possible, and some people have done it for SBCL at Google using bazel.io, though they never spent the time making it open source. I could extract bits from it and reproduce the same thing with ASDF, but I'd rather someone else do it, though I can explain what I see in those files.
Or then again, the CL community could adopt bazel (not very likely).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that, too. — Somerset Maugham (1874–1965)
On Thu, Sep 17, 2015 at 5:29 AM, Attila Lendvai attila@lendvai.name wrote:
is any of you interested in automating application delivery using ASDF? Now that I fixed ASDF's bundle operations and CFFI, the missing piece is the part where the bundled object files are linked against the runtime to produce a self-contained executable.
that^ sounds as if it was possible to generate e.g. an SBCL executable core that also includes the CFFI groveler generated .a or .so files linked into it. is that possible?
a cursory look suggests that it is, but not trivial at all:
https://stackoverflow.com/questions/9449845/how-to-link-object-file-to-execu...
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- Stupidity is an attitude.
It's possible, and some people have done it for SBCL at Google using bazel.io, though they never spent the time making it open source. I could extract bits from it and reproduce the same thing with ASDF, but I'd rather someone else do it, though I can explain what I see in those files.
does it happen a) from a final linking phase linking sbcl's .o files b) or using a vanilla sbcl exe (or executable core) and hacking the grovelled .o or .so files into it?
Or then again, the CL community could adopt bazel (not very likely).
from a strictly engineering perspective, do you think using bazel to build cl code would be better than using ASDF? yes/no/hard-to-judge?
to me it seems that it's an important ability to customize the build system from the .asd (because it's the same language), and that would be lost with bazel, no?
feel free to ignore all of this, just random curiosity...
On Thu, Sep 17, 2015 at 2:46 PM, Attila Lendvai attila@lendvai.name wrote:
It's possible, and some people have done it for SBCL at Google using bazel.io, though they never spent the time making it open source. I could extract bits from it and reproduce the same thing with ASDF, but I'd rather someone else do it, though I can explain what I see in those files.
does it happen a) from a final linking phase linking sbcl's .o files b) or using a vanilla sbcl exe (or executable core) and hacking the grovelled .o or .so files into it?
a libsbcl.a is produced, that will be linked against to produce a core, that will itself be used to dump the final image and create a standalone executable (or somehow combined with an image produced by another core? I don't think so, but I haven't read that part of the code.)
Or then again, the CL community could adopt bazel (not very likely).
from a strictly engineering perspective, do you think using bazel to build cl code would be better than using ASDF? yes/no/hard-to-judge?
If you have lots of memory and CPUs, and a Java heart with a Python skin don't work as a repellant on you, bazel is actually a pretty nice way to build software in a massive parallel way (though the distributed backend isn't open source (yet?), only the parallel backend on a single box, AFAIK). But it's very different from ASDF, and doesn't scale down to smaller machines (unless you have that distributed backend with a farm of smaller machines). So it's not going to displace ASDF any time soon.
Stelian had ideas about making a more blaze-like build system for CL; some ideas of my old XCVB could be resurrected, and I created a TODO for a hypothetical ASDF 4 that would be mostly backward compatible with ASDF 3, yet provide the benefits of a modern build system. However, I'm not convinced there's a large enough public to justify this work, unless you're going to make a general purpose rival to bazel.
to me it seems that it's an important ability to customize the build system from the .asd (because it's the same language), and that would be lost with bazel, no?
Bazel has this Skylark extension language (Python subset) that I'm working on. Not remotely as nice as CL.
On the other hand, CL is the wrong language to restrict side-effects, as required for a truly deterministic build system.
Haskell Cabal, anyone?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Pascal is for building pyramids—imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms… – Alan Perlis
-
Attila Lendvai -
Faré