FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-19-2010, 03:10 AM
Toshio Kuratomi
 
Default Building sources twice

We have a few packages that need to build themselves from their sources
twice. For instance, vim builds three times (a minimal version for /bin/vi,
and two versions with more dependencies for /usr/bin/vim and
/usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll have
some more with packages that build both python2 and python3 modules from
source that undergoes an automated transformation as part of its build.

So there's approaches to doing this:

1) Copy the source tree and build in both places
2) Build once with the python2 interpreter, copy the results away, and then
build a second time with python3.

vim takes a C version of option #2 (build with one set of configure options,
copy the results; make clean; and build with another set of options) but I'm
not sure there's a reason for that. It uses less disk space as we don't
have to duplicate the source tree. However, in software that might pollute
its source tree when it builds (maybe substituting file paths directly into
a source file, for instance), this could break.

Are there other reasons than I see for doing #2?

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-19-2010, 01:47 PM
Joe Orton
 
Default Building sources twice

On Mon, Jan 18, 2010 at 11:10:34PM -0500, Toshio Kuratomi wrote:
> We have a few packages that need to build themselves from their sources
> twice. For instance, vim builds three times (a minimal version for /bin/vi,
> and two versions with more dependencies for /usr/bin/vim and
> /usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll have
> some more with packages that build both python2 and python3 modules from
> source that undergoes an automated transformation as part of its build.
>
> So there's approaches to doing this:
>
> 1) Copy the source tree and build in both places
> 2) Build once with the python2 interpreter, copy the results away, and then
> build a second time with python3.
>
> vim takes a C version of option #2 (build with one set of configure options,
> copy the results; make clean; and build with another set of options) but I'm
> not sure there's a reason for that. It uses less disk space as we don't
> have to duplicate the source tree. However, in software that might pollute
> its source tree when it builds (maybe substituting file paths directly into
> a source file, for instance), this could break.
>
> Are there other reasons than I see for doing #2?

You should never be running "make clean" and rebuilding an existing
source tree to produce a differently-configured binary, this will break
debuginfo generation.

Most projects should allow use to use "VPATH" builds where
srcdir!=builddir, if not it is generally pretty simple to fix up the
Makefiles to support this. Generally you'll do:

mkdir build-one && cd build-one
../configure --some-options
make
cd ..
mkdir build-two && cd build-two
../configure --other-options
etc

Regards, Joe
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-19-2010, 05:18 PM
Toshio Kuratomi
 
Default Building sources twice

On Tue, Jan 19, 2010 at 02:47:54PM +0000, Joe Orton wrote:
> On Mon, Jan 18, 2010 at 11:10:34PM -0500, Toshio Kuratomi wrote:
> > We have a few packages that need to build themselves from their sources
> > twice. For instance, vim builds three times (a minimal version for /bin/vi,
> > and two versions with more dependencies for /usr/bin/vim and
> > /usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll have
> > some more with packages that build both python2 and python3 modules from
> > source that undergoes an automated transformation as part of its build.
> >
> > So there's approaches to doing this:
> >
> > 1) Copy the source tree and build in both places
> > 2) Build once with the python2 interpreter, copy the results away, and then
> > build a second time with python3.
> >
> > vim takes a C version of option #2 (build with one set of configure options,
> > copy the results; make clean; and build with another set of options) but I'm
> > not sure there's a reason for that. It uses less disk space as we don't
> > have to duplicate the source tree. However, in software that might pollute
> > its source tree when it builds (maybe substituting file paths directly into
> > a source file, for instance), this could break.
> >
> > Are there other reasons than I see for doing #2?
>
> You should never be running "make clean" and rebuilding an existing
> source tree to produce a differently-configured binary, this will break
> debuginfo generation.
>
> Most projects should allow use to use "VPATH" builds where
> srcdir!=builddir, if not it is generally pretty simple to fix up the
> Makefiles to support this. Generally you'll do:
>
> mkdir build-one && cd build-one
> ../configure --some-options
> make
> cd ..
> mkdir build-two && cd build-two
> ../configure --other-options
> etc
>
<nod> Projects built using automake should understand VPATH. I'm not sure
if python extension modules (built with distutils) would but copying the
source should work there if VPATH doesn't.

It sounds like C apps that currently do #2 should be switched over to either
VPATH or copying the source directory as well.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-19-2010, 05:42 PM
Orion Poplawski
 
Default Building sources twice

On 01/19/2010 07:47 AM, Joe Orton wrote:
> Most projects should allow use to use "VPATH" builds where
> srcdir!=builddir, if not it is generally pretty simple to fix up the
> Makefiles to support this. Generally you'll do:
>
> mkdir build-one&& cd build-one
> ../configure --some-options
> make
> cd ..
> mkdir build-two&& cd build-two
> ../configure --other-options
> etc
>
> Regards, Joe

and you can now do:

%global _configure ../configure

%configure --options

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-19-2010, 05:57 PM
Dennis Gilmore
 
Default Building sources twice

On Monday 18 January 2010 10:10:34 pm Toshio Kuratomi wrote:
> We have a few packages that need to build themselves from their sources
> twice. For instance, vim builds three times (a minimal version for
> /bin/vi, and two versions with more dependencies for /usr/bin/vim and
> /usr/bin/gvim). Working on the python3 Guidelines, it looks like we'll
> have some more with packages that build both python2 and python3 modules
> from source that undergoes an automated transformation as part of its
> build.
>
> So there's approaches to doing this:
>
> 1) Copy the source tree and build in both places
> 2) Build once with the python2 interpreter, copy the results away, and then
> build a second time with python3.
>
> vim takes a C version of option #2 (build with one set of configure
> options, copy the results; make clean; and build with another set of
> options) but I'm not sure there's a reason for that. It uses less disk
> space as we don't have to duplicate the source tree. However, in software
> that might pollute its source tree when it builds (maybe substituting file
> paths directly into a source file, for instance), this could break.
>
> Are there other reasons than I see for doing #2?
>
> -Toshio

snort builds 9 times for different options.

it uses approach number 2

Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org