You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2001/08/24 15:20:27 UTC

Build System Problems!

Hey All,

Just for fun I went to try to install a version of svn on a system that doesn't
have the auto* tools.  So what I did is check out the code, then copy my
configure scripts etc to the machine.  I then found I needed to copy 
build-outputs.mk as well.  The problem began then.

This other system also didn't have DB or Apache, so I was set for a client
build right?  Wrong!  build-outputs.mk includes the dependencies for fs and
mod_dav_svn stuff. How are we going to get around this since build-outputs.mk
is supposed to be a distributed file, but it depends on whether or not we have
DB and Apache?
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Build System Problems!

Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Aug 24, 2001 at 04:39:21PM +0100, Joe Orton wrote:
> On Fri, Aug 24, 2001 at 11:20:27AM -0400, Kevin Pilch-Bisson wrote:
> > Hey All,
> > 
> > Just for fun I went to try to install a version of svn on a system that doesn't
> > have the auto* tools.  So what I did is check out the code, then copy my
> > configure scripts etc to the machine.  I then found I needed to copy 
> > build-outputs.mk as well.  The problem began then.
> 
> The best way to do this is get a vanilla checkout on your development
> machine (which has auto* installed), put apr, neon in there then run
> autogen.sh. Then tar that tree up and you can put it on your build 
> machine (which doesn't have auto*), untar, and run configure.

I just tried this, and make is fine.  However I can't 'make install', because
intall-libs depends on libsvn_fs, etc, and install-bin depends on svnadmin, and
so on.  Something is going to have to be done to those install targets 
during the configure step.  I'll take a look at this right now.
> 
> (The dist.sh script might do this too, I haven't tried it)
> 
> joe
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Build System Problems!

Posted by Joe Orton <jo...@manyfish.co.uk>.
On Fri, Aug 24, 2001 at 11:20:27AM -0400, Kevin Pilch-Bisson wrote:
> Hey All,
> 
> Just for fun I went to try to install a version of svn on a system that doesn't
> have the auto* tools.  So what I did is check out the code, then copy my
> configure scripts etc to the machine.  I then found I needed to copy 
> build-outputs.mk as well.  The problem began then.

The best way to do this is get a vanilla checkout on your development
machine (which has auto* installed), put apr, neon in there then run
autogen.sh. Then tar that tree up and you can put it on your build 
machine (which doesn't have auto*), untar, and run configure.

(The dist.sh script might do this too, I haven't tried it)

joe


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Build System Problems!

Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Aug 24, 2001 at 12:47:50PM -0700, Greg Stein wrote:
> The theory is that build-outputs.mk has all the various build instructions,
> but the main Makefile chooses which to use. This is why there is @FS_RULES@
> and @BUILD_APACHE_RULE@ in the local-all target in Makefile.in.
> 
> However, the install target in build-outputs.mk was not so careful, as you
> found. It depends unconditionally on libsvn_fs. The "right" thing is to have
> install-libs and install-fs-libs. The Makefile.in will then select one or
> both for installation.
> 
> IOW, a simple bug... not something to go ballistic about.

Agreed, and I have just finished implementing that. (except I chose
install-lib-fs for the target).  Don't want to check it in until I finish
testing (probably Monday) though.
> 
> Cheers,
> -g
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson                    http://www.pilch-bisson.net
     "Historically speaking, the presences of wheels in Unix
     has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Build System Problems!

Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 24, 2001 at 11:20:27AM -0400, Kevin Pilch-Bisson wrote:
>...
> This other system also didn't have DB or Apache, so I was set for a client
> build right?  Wrong!  build-outputs.mk includes the dependencies for fs and
> mod_dav_svn stuff. How are we going to get around this since build-outputs.mk
> is supposed to be a distributed file, but it depends on whether or not we have
> DB and Apache?

The theory is that build-outputs.mk has all the various build instructions,
but the main Makefile chooses which to use. This is why there is @FS_RULES@
and @BUILD_APACHE_RULE@ in the local-all target in Makefile.in.

However, the install target in build-outputs.mk was not so careful, as you
found. It depends unconditionally on libsvn_fs. The "right" thing is to have
install-libs and install-fs-libs. The Makefile.in will then select one or
both for installation.

IOW, a simple bug... not something to go ballistic about.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org