Discussion:
Best practices analogous to "debug" and "release" builds?
John Morrison
2017-03-16 21:22:15 UTC
Permalink
Hi;

I want to prune all the developer-centric stuff (e.g., clouseau:inspector,
which in turn, brings in McCLIM, maybe some formatted I/O) from my CL
software when I package it as a dumped SBCL image (vs delivering source).
Would also like to change the optimize directives (debug, speed, etc.).

What are the best practices? My Googling didn't turn up much. Or am I
thinking about this in entirely the wrong way?

Thanks in advance,

-jm
Faré
2017-03-16 21:57:57 UTC
Permalink
On Thu, Mar 16, 2017 at 5:22 PM, John Morrison
Post by John Morrison
I want to prune all the developer-centric stuff (e.g., clouseau:inspector,
which in turn, brings in McCLIM, maybe some formatted I/O) from my CL
software when I package it as a dumped SBCL image (vs delivering source).
Would also like to change the optimize directives (debug, speed, etc.).
What are the best practices? My Googling didn't turn up much. Or am I
thinking about this in entirely the wrong way?
1- Whether using bazel or asdf, have a build script that does it all
for you, repeatably. If using ASDF, be sure to have separate
ASDF_OUTPUT_TRANSLATIONS for that build as compared to the usual
build.

2- Run tests from the production image, even if that means running
twice. But don't run them in the production environment!

3- The quux tarball on qitab shows what infrastructure ITA used to use
in QRes. The bazelisp repository shows what infrastructure Google uses
in QPX.

4- Either bazel or a recent CFFI + ASDF will help you deliver
single-file applications with custom libraries statically linked into
the image.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Always remember that you are unique. Just like everyone else.

Loading...