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

[Nic Ferrier]

Julian Scheid <address@hidden> writes:

> Looks good to me. 
>  
> Am I right that 
>  
>  >>   $ autoconf amjconfigure.in > configure 
>  >>   $ chmod u+x configure 
>  >>   $ ./automakejar Makefile.in 
>  
> is only necessary during development/before deployment, the 
> standard 
>  
>  >>   $ ./configure 
>  >>   $ make [all] 
> (    $ make install ) 
>  
> still applies for "end users"? In this case I have no objections, 
> looks like a clean and useful approach. 

That's right. As long as we distribute the Makefile.in (which is
derived from the automakejar processing).

And normally the first step for the build developer would be
different to because it would just be:

  $ autoconf

It isn't at the moment because we have an automake autoconf.


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

  
> One more suggestion, I think this: 
>  
>  > # You must run the automakejar script on this Make file to 
>  > # cause the target to be legal Make syntax. 
>  > texinfo-doclet.jar: 
>  >    sourcedir=$(SOURCEDIR) 
>  >    sourcefiles=$(SOURCEFILES) 
>  >    classpath=$(JAVAHOME)/lib/tools.jar 
>  >    classesdest=classes 
>  
> would be more clear if the special variables (sourcedir etc.) 
> processed by your sed scripts were prefixed in some way, perhaps 
> with a special character not used by GNU Make/Autoconf which 
> gives a visual clue that these lines are template lines and 
> preprocessed by your tool. Like autoconf using the @...@ 
> notion, which makes elements processed by autoconf (by ./configure, 
> to be exact) easily recognizable. 
>  
> 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.


> BTW was it your intent to put automakejar under that? 
>  > # (C) Tapsell-Ferrier Limited 2002
> <address@hidden> 

It's just my standard (c). I'm happy to assign automakejar to the FSF
if they're interested in having it.


Nic