Re: make check-exec-image failure

[<Joe...@t-...>]

Hi,

>But what I need is that "make check" does not abort prematurely, because a "make check" failure
>means - to everyone - "the package is broken, you should better not proceed with 'make install'".
I've always wondered whether distros use "make check" before releasing a package.
I have some doubts though, because I remember reading bugs that one would think impossible
had people used make check as a prerequisite.
Of course, make check probably works only on the target platform, not the cross-compiler build farm?

IMHO "make check" is important, because it ensures that basic CLISP functions work,
including GC and sockets (even some FFI tests).


I find a maintainer's attitude reasonable: Each and every warning is puzzling and costs
time ("is it or not the sign of a problem?"). As such, supplying options to force the
desired semantics, such as -fwrapv -fno-strict-aliasing and *not* silencing warnings
(assuming -fwrapv will silence those related to overflows) is an approach that should
satisfy both maintainers, developers as well as users occasionally compiling code. The
compile log will contain few warnings *and* the program will not crash from GCC
"optimizations" in obscure (rarely used) areas of the code.

Forcing the desired semantics should also have the additional benefit of allowing GCC's
highest optimization levels (-O3 to -O6), but that's another story.


>So, when users ask for a "single executable" option, tell them that this option would buy them nothing.

Maybe we could differentiate user expectations by target platform?
- MS-Windows: single file mostly welcome (think "portable executable (PE)"). 
Self-extracting and executing archives are common.

- trad. UNIX: used to packages and support files in /lib /usr /etc
Yet Sam put in effort to support that too, several years ago...
(I remember other tricks, like a file beginning as a tiny shell script,
 then exit, followed by binary stuff).

A single file is nice because sometimes you lose track of what .mem belongs to what lisp.run.

- MacOSX: People are used to foo.app for GUI apps.
Some know that they can invoke apps on the CLI via e.g. /Applications/VLC.app/Contents/MacOS/VLC
I have no idea whether a CLISP.app structure would make sense for a program that
only lives on the command line, i.e. whether an .app is expected to follow some
protocol, such as opening an event loop and responding to a WM startup notification message?

My expectation: When starting CLISP.app, (Saveinitmem ... :executable t) would
create another .app, somewhere else.

Another approach (involving several files): I've often created clickable files named
*.desktop (on Linux) and *.command (OSX) that start a terminal and a program therein.
The icon file is separate (.desktop) or in the resource fork (.command).
That's all I need, but others did not seem impressed by my approach ;-)

Regards,
	Jörg