: protocol
$(MAKE) -C src/client all
server : protocol
$(MAKE) -C src/server all
protocol :
$(MAKE) -C src/protocol all
Hope this helps,
Marc Alff.
s contains common rules that depends on variables set (or
not) in the body of each Makefile.am
Hope this helps,
Marc Alff
a selective -- and granted, at your own
risk -- clean.
> That said, if one inspects the Automake generated Makefile, it does
> not take long to learn how to create specific clean targets which will
> work for a specific target.
>
> Bob
Marc Alff.
tchize wrote:
However, i'd like to have this set of rules be replicated all
my source Makefile.am. To prevent manageability problems, i'd like to
know if there is a way to give automake a set of rules to inject all
generated Makefile.in of my projet without ressorting to an ugly
manual cut and p
and I can make one.
Also, keep in mind this enhancement is not part of the official automake
release yet,
but I hope to convince Alexandre (and Ralf for a change in libtool) at
some point,
and seeing if it solves your problem will work towards that :)
Let me know how I can assist you with all this.
If your code is public and available on the web, I can look at it and at
the Makefile.am changes.
Hope this helps,
Marc Alff.
ally finish the automake patch (for shared
objects)
and write the documentation :-)
Cheers,
Marc Alff.
t topic).
- with my proposal, changes would be on automake only to provide a
syntax to use libtool "as-is",
- with your proposal -- if I understand correctly --, changes would be
on libtool only (new -use-as-whole-archive flag)
to avoid using relocatables, so that it works with the current automake
by overloading existing syntaxes.
What did I miss ?
Since there is a change involved in each case,
the best would probably to put the change where it makes the more sense.
I can be convinced in other ways (beer helps too),
but my take so far is that it's about exposing in automake things that
libtool can do already.
Cheers,
Marc Alff.
the real coverage).
That's all for now, sorry if it's a bit off list.
I hope this helps with ideas.
Cheers,
Marc Alff.
I need to look closely at the generated makefiles for *.lo today,
and the generated code will use $(OBJEXT) or whatever makes sense)
Ouch, long post.
I know it's a lot of details to digest (I am digesting more of libtool
myself).
Thanks a lot Alexandre for your previous comments:
you can see by this post that they are taken into account.
While this project matures (Since I now have a work item for another patch),
everyone please post comments or questions if you have any :
I will be glad to correct missing parts sooner rather that later,
so reviews are most welcome.
Thanks all,
Marc Alff.
hy is that dependencies are created **during** the build,
as a side effect of compiling a *.c or *.cpp file.
Look at directories named ".deps", they contains "*.Po" files,
which are Makefile fragments listing the dependencies for a file.
I hope this helps,
Marc Alff.
Marc Alff wrote:
This is the discussion thread; a proposed patch is available on
automake-patches --at-- gnu.org
The post for the patch is here :
http://lists.gnu.org/archive/html/automake-patches/2006-03/msg00024.html
Cheers,
Marc Alff.
for discussion, and possibly inclusion
in the "official" Automake code base.
Thanks all for your comments,
and thanks to Ralf Wildenhues for early comments and suggestions that
encouraged this babble :)
Cheers,
Marc Alff.
Hi all.
If that helps, this is how I use Flex & Bison with Automake :
http://cvs.sourceforge.net/viewcvs.py/yaorb/yaorb/src/cpp/dev/idlc/Makefile.am?only_with_tag=MAIN&view=markup
-- Marc.
Kototama wrote:
Hi,
I added the header file generated by automake/bison in BUILT_SOURCES but
when I t
13 matches
Mail list logo
