Re: Autotools: compiling two C++ files with two compilers...

[Ralf Wildenhues]

Hello Federico,

* Federico Zenith wrote on Fri, Jan 12, 2007 at 02:07:36AM CET:
> sorry if the question may be lame, but it's my first package with
> Autotools...

Actually, the question is all but lame.  There are quite subtle issues
attached to this issue.

> I have tried redefining the CXX variable (as it is done in a configure.base
> file in Octave-Forge project: is that an old autoconf stuff?), and now I am
> pretty much trying to add a GNU-Make rule (without the various autotools
> magic). Yet, this really should not be this difficult: I want to compile a
> file with a compiler and another file with another compiler. I must be
> missing something big time!

Well.  Strictly speaking, you can even only use one compiler (per
language) per configure script, let alone per Makefile.am, so you'd have
to write a package with two (nested) configure scripts then.  Why is
that?  Well, configure tests compiler features (among others), and there
is no abstraction in Autoconf except for source language (C, C++,
Fortran, ...).  (BTW, a package that is to be cross-compiled but also
needs a compiled program for building, is in a comparable situation.)

But in practice, I don't think you will need all this: I assume the
mkoctfile compiler wrapper behaves more or less like $CXX, or otherwise
has some known fixed behavior.  So let's only worry about that if we
cannot fix it more easily.  In the following, I'll ignore all
Autoconf-related questions and discuss only the Automake side of
overriding it gracefully.

You're right in that you should be able to override things in a
Makefile.am on a per-target/per-rule/per-variable basis.  And generally,
that's right.  Except there are some things to note:

> if MKOCTFILE
> noinst_PROGRAMS += correlationMatrix
> endif

Now here you're telling automake that it has responsibility to come up
with compile and link rules for correlationMatrix, ...

> correlationMatrix_SOURCES = correlationMatrix.cpp

... and that these are its source files, to be distributed and compiled.
Including dependency tracking code and all.

If you want to override the rules generated, you'd have to do that one
by one: write a rule for correlationMatrix$(EXEEXT) from the object
file, and one for the object file.  Hmm.  The object's file name is
correlationMatrix.$(OBJEXT), but strictly speaking, this is an internal
detail of Automake (in some cases it renames/has to rename object files)
so actually you should not use it.

So what we do is avoid the _PROGRAMS primary at all, so automake doesn't
even start thinking about throwing its machinery at correlationMatrix.
Since automake disallows _DATA in bindir (somewhat understandably), we
have the option of either writing our manual install-exec-local and
uninstall-local rules for it, or we can let automake assume that
correlationMatrix is a (generated) script: the naming is a bit
unfortunate, but really it doesn't matter much whether the file is
binary or not from an automake POV.  Since the $(EXEEXT) magic only
works with *_PROGRAMS, we'll have to add it manually everywhere now:

bin_SCRIPTS = correlationMatrix$(EXEEXT)

Now to the build rule:

> correlationMatrix: correlationMatrix.cpp
>         mkoctfile $(srcdir)/correlationMatrix.cpp

Almost correct, except for the $(EXEEXT) bit (obviously you can ignore
that if you don't care about w32, but if this is public software, then
your users just may care).  And you want to use the nice MKOCTFILE macro
you put so much work in to define:

correlationMatrix$(EXEEXT): correlationMatrix.cpp
        $(MKOCTFILE) -o $@ $(srcdir)/correlationMatrix.cpp

Almost done now.  What's missing for 'make distcheck' to pass, is that
we have to distribute the source file, and clean the binary upon 'make
clean':

CLEANFILES = $(bin_SCRIPTS)
EXTRA_DIST = correlationMatrix.cpp

Voilà.

Hope that helps.  You may want to ask Automake-related questions on the
automake list, there's more people listening there.

[...]
> target to the latter (which however does not change much, I still get
> the error only written once instead of twice).

Please *always* include the exact error message when reporting a bug or
asking for help.  It's ok if you also describe it, but seeing the exact
error message is very important.

Cheers,
Ralf