On Thu, Nov 13, 2008 at 09:09:39PM +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
This does work:
maude_SOURCES = maude/maude.processed.cpp
EXTRA_maude_SOURCES = maude/maude.cpp
.cpp.processed.cpp:
python $(top_srcdir)/myscript.py $<
mkdir -p `dirname [EMAIL PROTECTED]
cp $< $@
SUFFIXES = .cpp .processes.cpp
However, I would really like to avoid duplicating every source file in
maude_SOURCES and EXTRA_maude_SOURCES (the necessity to write a custom
make clean and duplicated TAGS entries being other minor points). Is
adding pre-compilation hooks to automake a good idea? Or is there any
other way to do that?
> > 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?
I'm aware of the limitations of this approach. Do you see an alternative
for the described use case?
> > 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).
Good to know, thanks for the info! I'll try that if I manage to solve
other problems.
With kind regards,
--
Baurzhan Ismagulov
http://www.kz-easy.com/
