Hello Baurzhan, * Baurzhan Ismagulov wrote on Thu, Nov 13, 2008 at 11:10:47AM CET: > On Wed, Nov 12, 2008 at 09:34:22PM +0100, Ralf Wildenhues wrote: > > 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.
What a brain-damaged design. Can you give it options to write to a different file? Does it at least update the file atomically? Here's why this is so problematic, even independently of being awkward to leverage in a Makefile: Even if it updates the file atomically: when the process is interrupted, or the system goes down, it is not clear whether the file contains the old or the new version now. If the update is not atomic, then it may even be that you get neither the old nor the new version, but just a broken file. I can only warn against using such dangerous tools. Ah, and then I haven't even thought of w32 file semantics yet: when you happen to have the source file open in an editor, the tool may not even be able to update it. Hmm, in this case that could even be construed as a feature. > 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? I guess; and you should probably put maude.cpp in EXTRA_DIST and/or EXTRA_maude_SOURCES. And take measures to clean generated files appropriately; depending on whether they are shipped (then they should be updated in the source tree, and only maintainer-cleaned) or whether the user needs to rebuild them (then they should be in the build tree and probably cleaned with 'make clean'). > 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. Hmm. > 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? Well, depcomp has a 'msvisualcpp' dependency mode (to have it tried you need --enable-dependency-tracking, too). I have no idea whether it works. I looks like it needs cygpath, so will probably not work without Cygwin. If somebody could test it, I'd be interested to hear results. Of course I'd also accept a patch to make it work with MinGW (using the 'cmd //c' idiom for translating paths, for example). Cheers, Ralf
