On Mon, Jan 3, 2011 at 5:13 PM, Samium Gromoff <_deepf...@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
fake-knowledge.lsp
Description: Binary data
------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
