automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overriding suffix based implicit rules


From: Ralf Wildenhues
Subject: Re: Overriding suffix based implicit rules
Date: Tue, 27 Mar 2007 21:56:46 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Artus,

* Artus wrote on Tue, Mar 27, 2007 at 02:40:06PM CEST:
> 
> What shoul I write in Makefile.am to inform automake that .c files in this
> specific directory are C++ source files and not C files? I tried the
> following with no sucess (and I do not want to rename the files).

Well, renaming the files is the way to go, though.
Not only does Automake infer from suffix, so do some
compilers.  For example, if you care about portability
to MSVC, .cpp is the only suffix that we know of that
works well.  Otherwise, .cc is ok as well; if you don't
care about portability to case-insensitive file systems,
then .C will do as well.

It may help to switch to a more powerful version control
system to avoid losing the history over a rename, if that's
the reason you don't want to do the switch.

> # Makefile.am
> .c.o:
>       $(CXX) $(CXXFLAGS) -c $< -o $@
> lib_LTLIBRARIES = libadn.la
> libadn_la_SOURCES = adn.h adn.c tim.c cyto.c

Libtool objects use the suffix .lo, and you should use libtool to
compile, so the rule should probably look something like this:

.c.lo:
        $(LTCXXCOMPILE) -c -o $@ $<

Please note that LTCXXCOMPILE is not documented, i.e., an internal
detail of Automake that could change in a future version.  And also
the names of the corresponding object files are not a public
interface either.  Practically, this currently means that you may
not use per-target compile flags for libadn.la, otherwise the above
won't work as expected.

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]