RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2Makefile

[GOMEZ Henri <hg...@slib.fr>]

>Ok. ( plus ant )

of course ;)

>But I'm not sure I understand why do we need automake - if autoconf
>can generate only the build.properties file ( and probably a .h ). 

I think automake was used to generate the stuff for static build
but I removed now.

>The makefile and ant should read the build.properties to get settings
>to use ( and that will also allow manual config ).

Do you agree having build.properties generated by autoconf ?

>I would like more info on what is autoconf detecting - and make sure 
>we don't duplicate stuff that was detected by apache ( and end up with
>different settings for apache and jk ). In general, I would like the 
>2 'styles' work togheter - and the user is able to specify 
>it's explicit 
>preferences in build.properties-style, and autoconf will just 
>guess the 
>rest.

I'll commit today the new autoconf stuff, remove automake and
you could see that the autoconf is really simple (apxs/apr src/apr inc,lib)

>It is very common to build the .so on a system and deploy it on another
>system ( the production server is not a build machine in most cases ),
>and I want to be sure the user can contol explicitely what options are 
>used.

For sure, as an rpm packager it's one of my primary concern 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2Makefile

[co...@covalent.net]

On Tue, 14 May 2002, GOMEZ Henri wrote:

> >The makefile and ant should read the build.properties to get settings
> >to use ( and that will also allow manual config ).
> 
> Do you agree having build.properties generated by autoconf ?

+1.

I don't mind if it also tries to 'guess' locations for the other packages
we use ( like looking in /usr/share/java ). 

Is it possible to generate build.properties from build.properties.sample
( instead of .in ) ? Not a big deal, but it would be nice.



> >It is very common to build the .so on a system and deploy it on another
> >system ( the production server is not a build machine in most cases ),
> >and I want to be sure the user can contol explicitely what options are 
> >used.
> 
> For sure, as an rpm packager it's one of my primary concern 

I know :-)

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>