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 _______________________________________________ help-gnu-utils mailing list help-gnu-utils@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnu-utils