[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cp-tools-discuss] automakejar based build system

From: Julian Scheid
Subject: Re: [Cp-tools-discuss] automakejar based build system
Date: Wed, 24 Apr 2002 13:32:19 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417

Nic Ferrier wrote:
Julian Scheid <address@hidden> writes:

As a side node, wouldn't it make sense to have automakejar operate on Makefile.in by default, as in './automakejar'?

Well, it's useful to have automakejar try to make a Makefile.in by
default because sometimes one doesn't use autoconf. I've been
thinking that automakejar should scan the current directory for the
configure files and output to Makefile.in if it finds them.

What I meant was that if automakejar is called without parameters, and
a Makefile.in exists in the current directory, it would probably make
sense for automakejar to process this file and apply the sed scripts.

Another approach could be to bracket the assignments into a block of some kind, indicating that something like a macro is executed here. I think either approach would increase readability and eliminate possible confusion.

Interesting point. I don't particularly like the idea of a prefix or
a block construct... the real point is that these things are NOT make
targets, they are automakejar targets, but they are still targets, you
can even add dependancies like this:

texinfo-doclet.jar: some-dependancy  another-dependancy
sourcedir=$(SOURCEDIR) sourcefiles=$(SOURCEFILES) classpath=$(JAVAHOME)/lib/tools.jar classesdest=classes
As it stands the automakejar target is quite useful because it is a
bunch opf variables and syntactically won't have any effect under

Agree, but I'd still find it helpful to have some kind of visual clue
indicating that this target/these variable assignments do have a
special meaning not covered by the standard GNU Make semantics.


reply via email to

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