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

[Julian Scheid]

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
> make.

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.

Julian