[Ecls-list] Help needed, really

[Juan Jose Garcia-Ripoll]

On Mon, Jan 3, 2011 at 5:13 PM, Samium Gromoff
<_deepfire at feelingofgreen.ru>wrote:

> My impression was that ECL doesn't /add/ information anywhere -- it merely
> /forwards/ whatever is fed to it by autoconf.  It's not intent, merely a
> lack of sophistication. Juan, am I right? [...]
> In other words -- garbage in, garbage out -- :I686 is what ECL got from
> autoconf.  If GCL copes with that -- it must be doing normalisation --
> which Juan is not interested in maintaining.


Yes, and there is a logic for that which is that I can not anticipate the
information or the nomenclature that is provided by different systems out
there, maintain it and normalize it. I can't because I do not have that
information which is scattered over the documentation of multiple compilers,
software utilities, projects and intermediate tools such as Autoconf, X's
make, etc. Furthermore, I have demonstrated here my ignorance of the
appropriate naming, detection techniques and criteria for detecting those
build modes.

The only reasonable thing that one may do, given that a C compiler and a
sensible linker are used, is to *reexport* additional information. I attach
one such possible utility which does not do any normalization at all, it
simply extracts some "keywords" from the output of "file" and from the
output of the C preprocessor, using the compiler flags that ECL was
supplied. The output is a list of keywords in *system-features* (not
*features*) randomly chosen after removing the standard C ones, which may or
may not be useful at all, because they have not been really normalised,
other than removing underscores here and there.

How useful this is, I do not know. If this file is found to be useful, I can
add it to the build phase. Note that I am not going to merge this list with
*features* because the list of items here is ultimately random and based on
potentially useful patterns of names and keywords that a user might find
interesting, and also because of the problem with feature name clutter.

I would also not maintain the list of keywords, because they are not needed
by ECL and because I have no criteria to add/remove them, or time and
resources to keep track of what compilers have exported, export or will
export in the future as compiler macros. At most I can, on demand, add new
names.

But note how the information that this program gathers comes from the C
compiler, which provides exactly the same information as "file": ELF,
compilation model (64 / 32 bits), etc, and I guess it is so for all
platforms. So *this information could have been equally easily retrieved
using standard autoconf tests and the output of "ecl-config"*. in a more
reliable way, as *the person writing the test would know what he/she is
looking for which I do not.*

Juanjo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110104/4d55045e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fake-knowledge.lsp
Type: application/octet-stream
Size: 4469 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110104/4d55045e/attachment.obj>