Possible extension, to make porting easier (autoport)

[Christian Leber]

Hello

(sorry for my bad english and the logical flaws)

This is just an (possibly) stupid idea for a autoconf extension.
I just would like to discuss this and i think this mailinglist is
the right place for this.

I call it autoport (so that it's more clear what i mean).

Because i was a beginner to autoconf and i've needed a lot of time to
learn to use only a little bit of the possibilities to make my little
projekt (sit, cryptographic irc client) a little bit more portable.
Problems:
-for what i have to check for?
-what should i do with all the results?
-the annoying question: why do i try to make it portable?

So I think it could be possible to help maintainers with this hard
task, especially if they have no access to some systems witch could
be supported.

So my idea is to use in the sources replacement functions and types,
e.g. ap00_memcmp instead of just memcmp.
The automatically created included "libary" then could just define
#define ap00_memcmp memcmp
or compile a (8 bit clean) replacement and link this against the
programm.


(rough) EXAMPLE
        
Example c file:

include "autoport/ap00.h" 
int main()
{
        char *foo;
        ap00_32int bar;
        
        ap00_printf("%s\n","hello");
        foo = ap00_alloca(5);
        
        return(0);
}

Then the maintainer would have to create with autoport a configure.ac
with checks for a 32 bit integer, the existence of printf and the existence
of alloca (or if it's usable) and creates corresponding autoport/ap00.h.
(automatically from a "database") (how this could be done below)

The user of the package would untar it and run ./configure as normal.
This configure would then start the configure in the subdirectory witch
would check for the includesm, functions and types and so on, and create
the include file and possibly a small libary with the replacements.
(or break with a bad error if there is no way to make it run on the
system)

This would for example look at a modern GNU/Linux like this:
#include <stdio.h>
#include <stdlib.h>
#define ap00_32int int
#define ap00_printf printf
#define ap00_alloca alloca

On an older/obscure possibly like this:
#include <stdio.h>
#define ap00_32int long int
#define ap00_printf printf
#define ap00_alloca ap00_replace_alloca

and a libary would have to be created with an alloca replacement named
ap00_replace_alloca and linked against the programm.

The programm (autoport) could work (very rough) in this way:
1.) scanning all source files in the programm for functions supported
2.) creating a configure.ac with all needed checks and the possibility
    to create the right include file in a subdirectory
3.) copying all the avaible replacement stuff in the directory and creating
    the neccessary makefile or so

Advantages
-maintainers/developers would not have to check themselves for the
 existence of every (or nearly every) function they use.
-the maintainer would not have to search himself for replacement functions
-another nice thing:
 the programm could create a libary and include with all supported
 stuff, so the top level configure could find this and use it for
 the programm, so a lot of checks could be saved and the compilation
 of the possibly needed replacement stuff

Disadvantages
-possibly to much checks, because of example no one with an obscure
 system without alloca function uses the programm ever.
-very complex to implementat this
-a lot of (boring/annoying/hard) work to make this usable


I hope you got the idea.


So, what do you think?


Christian Leber