[Top][All Lists]

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

Re: pre- and post-compilation hooks

From: Baurzhan Ismagulov
Subject: Re: pre- and post-compilation hooks
Date: Thu, 13 Nov 2008 11:10:47 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Ralf,

It turned out I'm not subscribed to the list and have missed some
interesting stuff like less verbose.

On Wed, Nov 12, 2008 at 09:34:22PM +0100, Ralf Wildenhues wrote:
> > I'd like to migrate a SNiFF+ project to automake. So far, it looks quite
> > promising. Two issues:
> > 
> > 1. The compilation rule performs some custom pre-processing before
> >    actually calling the compiler; if pre-processing fails, the compiler
> >    is not called, and make is stopped.
> What is SNiFF+, what does it do?

It's a GUI, you define projects and sub-projects, it puts generic
Makefiles in the directories and generates make include files with
dependencies, and the rest (source files, output files) in variables. It
can build the project using bundled GNU tools from Cygwin.

For now, we're building the project with Eclipse and MSYS using the
SNiFF+ Makefiles. We still have one SNiFF+ license to add new files to
the project and to update dependencies.

> What are the input files?  If they
> have different suffixes than the compiler, you can just use a (suffix)
> rule to do the preprocessing.  Even if they have suffixes like .c, you
> might be able to hack it by writing a rule like
>   .c.processed.c:
>       command
>   SUFFIXES = .c .processed.c

Hmm, a nice trick! However, the preprocessor reads .cpp files, possibly
updates them and another tool's input file, and writes them back as
.cpp. With this workflow, I'm a bit confused how I could apply that. In
particular, assuming I hack the preprocessor to write back both
maude.cpp and maude.processed.cpp, should I define maude_SOURCES =
maude.processed.cpp in my

The sources contain log messages. Every message has an id. Whenever a
new log message is added, the developer puts the id of zero. The
preprocessor looks for the log function calls, replaces the ids that are
zero, updates the log interpreter's input file, and writes the source
file back. Replacing this in a way acceptable to my boss ;) and getting
rid of calling a Python script for every source file would also be an

> This will not be portable to some non-GNU make implementations, though.
> (I think automake may warn, too.)

Good to know. Not a big issue right now.

> > 2. The Tasking C166/ST10 compiler doesn't support generating
> >    dependencies, so I'd like to call gcc to do that if the compilation
> >    was successful.
> > 
> > How can I do that with automake?
> If you --enable-dependency-tracking, then depcomp will try "expensive"
> tracking methods, such as running 'makedepend'.

That is exactly what I asked for! Great to know automake supports this!

Meanwhile, I've found out that the command line help of Tasking's
front-end tool, cc166, doesn't mention all back-end tool options; it
turned out the C++ compiler, cp166, does support dependency generation.

While we are at it, does Visual Sudio's cl support dependency

With kind regards,
Baurzhan Ismagulov

reply via email to

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