Re: compiler wrappers

[Ralf Corsepius]

"Lars J. Aas" wrote:
> 
> Having one semi-functional compiler wrapper for MS Visual C++, and
> another one for Borland C++ coming along nicely, I've started thinking
> of how this should be integrated with the Auto-tools.
> 
> What I have come up with is a scheme something like this:
> 
> 1) The scripts are installed in $auxdir.
> 2) The script names are prefixed "com-" (for compiler option mangler)
>    (manipulator, merger, masker, morpher, whatever...).  "com-" is easily
>    associated with "compiler", so it seems like a suitable prefix.  The
>    two existing wrappers will be named com-vcc (com-msvc?) and com-bcc.
> 
> ?: Which package should deliver the wrappers - Autoconf or Automake?
IMO, they should be kept separate.

>    Autoconf doesn't have any autoconfiscate utility that adds scripts
>    and stuff, while Automake has the --add-missing option and installs
>    a set of scripts already. 
A situation, which I consider being worth reconsideration (cf. the
new features in autoconf wrt. cross-compilation with rely on
config.guess, config.sub etc.).

>  However, I feel they are more in the
>    realm of Autoconf than Automake.
> 
> With this scheme, configure can walk through $auxdir/com-* to check
> which compiler option manglers exist, and if any can be used on the host
> system.
IMO, you are just facing a cross-compilation and canonicalization
related issue (VC etc. under Cygwin - this is a special form of
cross compilation :).

Therefore I would apply the gnu-canonicalization naming scheme (e.g.
by naming your scripts i386-pc-vc-cc or similar), and add
appropriate support to config.guess, config.sub etc.

If you want to pick them up locally from your package, just pick
them them up from there just like any other built-tool required for
building a package.

> However, doing it alphabetically (the way they will be ordered when you
> glob $auxdir/com-*) will probably not be desirable, and you might want to
> be able to specify which compiler suite you want to use - something like
> --with-borland or --with-visual-c++ - 
IMO, this reads like being a similar approach as AC_CYGWIN has
(had?) been. It basically means abandoning a feature-check based
approach in favor of a table based approach. 

> and to support such options, there
> has to be an interface between configure and the manglers for configure
> to be able to extract important information like e.g. the name to be used
> in the --with- option.
> 
> Well, that's all the thoughts on the matter I care to air for now before
> getting some feedback.  Let it rip...

Ralf.