automake
[Top][All Lists]
Advanced

[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: Tue, 18 Nov 2008 16:22:38 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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 address@hidden
        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/




reply via email to

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