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 Makefile.am? 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 alternative. > 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. Wow. While we are at it, does Visual Sudio's cl support dependency generation? With kind regards, -- Baurzhan Ismagulov http://www.kz-easy.com/
