On 08/06/2012 10:41 AM, Jack Kelly wrote: > On Mon, Aug 6, 2012 at 5:38 PM, Stefano Lattarini > <stefano.lattar...@gmail.com> wrote: >> On 08/05/2012 11:45 AM, Michał Górny wrote: >>> My library was structured like the following: >>> >>> - src/foo (the header file), >>> >> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'? >> That would be unlikely to trigger unexpected problems in the first >> place ... > > I have a feeling it's mimicking the way modern C++ prefers `#include > <iostream>' over `#include <iostream.h>' > > I propose a third fix: move the header file into a separate directory > such as `include/' and add `-I$(top_srcdir)/include' to AM_CPPFLAGS. > This seems unwarranted complexity just for the sake of an eye-candy like "#include <foo>" over "#include <foo.h>". But of course, that is for the OP to decide.
> Is it worth providing a way to disable implicit rules as an option to > AM_INIT_AUTOMAKE or via the AUTOMAKE_OPTIONS variable? > Trying to do that portably would be a nightmare I think (assuming it would be possible at all). OTOH, Automake-NG (the Automake fork whose generated Makefiles only target GNU make) does that unconditionally (for performance rather than correctness reasons): <http://lists.gnu.org/archive/html/automake-ng/2012-06/msg00294.html> > It's not enough to pass --no-builtin-rules to AM_MAKEFLAGS as I don't > know if that's portable. > In fact, it's not. > Further, the MAKEFLAGS only get propagated to submakes: the > top-level make has already loaded the implicit rules before it sees > MAKEFLAGS. > Luckily, with GNU make, you can append to MAKEFLAGS in the Makefile: MAKEFLAGS += -r and have that take effect in the current make run as well. Regards, Stefano
