Re: Multiple configure-make cycles
On 04/27/02 01:18:06 +0200 Josselin Mouette wrote: > Hi, > > I am going to modify one of my packages so that two versions of the > software get built. Then I have to run the ./configure, make and make > install cycle twice. > However, the debian/rules file usually makes a difference between the > configure, build and install phases. What is the best way to deal with > it ? Is using 2 install targets depending on different build/configure > targets a good solution ? Instead of building in the source dir, create 2 build directories, cd to each and ../configure with different options. Then in the make section, cd into each build dir and make. So essentially you are building the different versions in parallel, rather than repeating them in a serial fashion. Even better than what I just said above is to make a source dir and 2 build dirs, like so: /source-tree /build1 /build2 /debian That way the source files are nicely separated from the build files. Binutils organizes itself this way. It uses some unpacking/patching scripts that are modular and should be able to fit into any package. Or perhaps, any package should be able to made to fit the scripts. :-) I'm not sure where the scripts originated from, but I'm sure someone here will know... -David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple configure-make cycles
David Caldwell <[EMAIL PROTECTED]> writes: > Even better than what I just said above is to make a source dir and 2 > build dirs, like so: > > > /source-tree > /build1 > /build2 > /debian > > That way the source files are nicely separated from the build files. > Binutils organizes itself this way. It uses some unpacking/patching > scripts that are modular and should be able to fit into any package. > Or perhaps, any package should be able to made to fit the scripts. :-) > I'm not sure where the scripts originated from, but I'm sure someone > here will know... Anybody interested should look at dbs -- it's packaged. Personally, I don't like hiding the source in its own tree, and not having it available immediately after "dpkg-source -x". dbs (or similar approaches) are almost mandatory to stay sane with packages requiring many changes to upstream source, but otherwise it just adds complication. -- Robbe signature.ng Description: PGP signature
Re: Multiple configure-make cycles
Hi, On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > Instead of building in the source dir, create 2 build directories, cd to > each and ../configure with different options. Then in the make section, cd > into each build dir and make. So essentially you are building the different > versions in parallel, rather than repeating them in a serial fashion. Look at the FOX library, it uses exactly this approach to build a default libfox0.99 and one with debugging libfox0.99-dbg. Greetings, Bastian msg06085/pgp0.pgp Description: PGP signature
Re: Multiple configure-make cycles
Le sam 27/04/2002 à 11:02, Bastian Kleineidam a écrit : > Hi, > > On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > > Instead of building in the source dir, create 2 build directories, cd to > > each and ../configure with different options. Then in the make section, cd > > into each build dir and make. So essentially you are building the different > > versions in parallel, rather than repeating them in a serial fashion. > > Look at the FOX library, it uses exactly this approach to build a > default libfox0.99 and one with debugging libfox0.99-dbg. Thanks, the way libfox acts is exactly what I was looking for. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Multiple configure-make cycles
Bastian Kleineidam wrote: > On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > > Instead of building in the source dir, create 2 build directories, cd to > > each and ../configure with different options. Then in the make section, cd > > into each build dir and make. So essentially you are building the different > > versions in parallel, rather than repeating them in a serial fashion. > > Look at the FOX library, it uses exactly this approach to build a > default libfox0.99 and one with debugging libfox0.99-dbg. That sounds redundant, what's wrong with building once with -g, linking shared, stripping, calling that one package, and then linking w/o stripping for the -dbg package? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple configure-make cycles
Hi,
On Sat, Apr 27, 2002 at 11:06:59AM -0400, Joey Hess wrote:
> That sounds redundant, what's wrong with building once with -g, linking
> shared, stripping, calling that one package, and then linking w/o
> stripping for the -dbg package?
The configure.in has different -D defines for debugging, so you have to
compile twice, one with --enable-release, the other with --enable-debug.
FOX has internal tracing (FXTRACE) and asserts (FXASSERT) macros that
are enabled when DEBUG is defined, disabled otherwise.
Greetings, Bastian
[configure.in snippet]
dnl Debugging turned on
AC_MSG_CHECKING(for debugging)
AC_ARG_ENABLE(debug,[ --enable-debug compile for debugging])
AC_MSG_RESULT([$enable_debug])
if test "x$enable_debug" = "xyes" ; then
CXXFLAGS="${CXXFLAGS} -g -DDEBUG"
fi
dnl Building for release
AC_MSG_CHECKING(for release build)
AC_ARG_ENABLE(release,[ --enable-releasecompile for release])
AC_MSG_RESULT([$enable_release])
if test "x$enable_release" = "xyes" ; then
CXXFLAGS="${CXXFLAGS} -O2 -DNDEBUG"
if test "${GXX}" = "yes" ; then
CXXFLAGS="${CXXFLAGS} -Wuninitialized -ffast-math -finline-functions
-fomit-frame-pointer -fexpensive-optimizations"
fi
fi
msg06094/pgp0.pgp
Description: PGP signature
Re: Multiple configure-make cycles
On 04/27/02 01:18:06 +0200 Josselin Mouette wrote: Hi, I am going to modify one of my packages so that two versions of the software get built. Then I have to run the ./configure, make and make install cycle twice. However, the debian/rules file usually makes a difference between the configure, build and install phases. What is the best way to deal with it ? Is using 2 install targets depending on different build/configure targets a good solution ? Instead of building in the source dir, create 2 build directories, cd to each and ../configure with different options. Then in the make section, cd into each build dir and make. So essentially you are building the different versions in parallel, rather than repeating them in a serial fashion. Even better than what I just said above is to make a source dir and 2 build dirs, like so: /source-tree /build1 /build2 /debian That way the source files are nicely separated from the build files. Binutils organizes itself this way. It uses some unpacking/patching scripts that are modular and should be able to fit into any package. Or perhaps, any package should be able to made to fit the scripts. :-) I'm not sure where the scripts originated from, but I'm sure someone here will know... -David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple configure-make cycles
David Caldwell <[EMAIL PROTECTED]> writes: > Even better than what I just said above is to make a source dir and 2 > build dirs, like so: > > > /source-tree > /build1 > /build2 > /debian > > That way the source files are nicely separated from the build files. > Binutils organizes itself this way. It uses some unpacking/patching > scripts that are modular and should be able to fit into any package. > Or perhaps, any package should be able to made to fit the scripts. :-) > I'm not sure where the scripts originated from, but I'm sure someone > here will know... Anybody interested should look at dbs -- it's packaged. Personally, I don't like hiding the source in its own tree, and not having it available immediately after "dpkg-source -x". dbs (or similar approaches) are almost mandatory to stay sane with packages requiring many changes to upstream source, but otherwise it just adds complication. -- Robbe signature.ng Description: PGP signature
Re: Multiple configure-make cycles
Hi, On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > Instead of building in the source dir, create 2 build directories, cd to > each and ../configure with different options. Then in the make section, cd > into each build dir and make. So essentially you are building the different > versions in parallel, rather than repeating them in a serial fashion. Look at the FOX library, it uses exactly this approach to build a default libfox0.99 and one with debugging libfox0.99-dbg. Greetings, Bastian pgp3Nm6ULCzsw.pgp Description: PGP signature
Re: Multiple configure-make cycles
Le sam 27/04/2002 à 11:02, Bastian Kleineidam a écrit : > Hi, > > On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > > Instead of building in the source dir, create 2 build directories, cd to > > each and ../configure with different options. Then in the make section, cd > > into each build dir and make. So essentially you are building the different > > versions in parallel, rather than repeating them in a serial fashion. > > Look at the FOX library, it uses exactly this approach to build a > default libfox0.99 and one with debugging libfox0.99-dbg. Thanks, the way libfox acts is exactly what I was looking for. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Multiple configure-make cycles
Bastian Kleineidam wrote: > On Fri, Apr 26, 2002 at 07:08:26PM -0700, David Caldwell wrote: > > Instead of building in the source dir, create 2 build directories, cd to > > each and ../configure with different options. Then in the make section, cd > > into each build dir and make. So essentially you are building the different > > versions in parallel, rather than repeating them in a serial fashion. > > Look at the FOX library, it uses exactly this approach to build a > default libfox0.99 and one with debugging libfox0.99-dbg. That sounds redundant, what's wrong with building once with -g, linking shared, stripping, calling that one package, and then linking w/o stripping for the -dbg package? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple configure-make cycles
Hi,
On Sat, Apr 27, 2002 at 11:06:59AM -0400, Joey Hess wrote:
> That sounds redundant, what's wrong with building once with -g, linking
> shared, stripping, calling that one package, and then linking w/o
> stripping for the -dbg package?
The configure.in has different -D defines for debugging, so you have to
compile twice, one with --enable-release, the other with --enable-debug.
FOX has internal tracing (FXTRACE) and asserts (FXASSERT) macros that
are enabled when DEBUG is defined, disabled otherwise.
Greetings, Bastian
[configure.in snippet]
dnl Debugging turned on
AC_MSG_CHECKING(for debugging)
AC_ARG_ENABLE(debug,[ --enable-debug compile for debugging])
AC_MSG_RESULT([$enable_debug])
if test "x$enable_debug" = "xyes" ; then
CXXFLAGS="${CXXFLAGS} -g -DDEBUG"
fi
dnl Building for release
AC_MSG_CHECKING(for release build)
AC_ARG_ENABLE(release,[ --enable-releasecompile for release])
AC_MSG_RESULT([$enable_release])
if test "x$enable_release" = "xyes" ; then
CXXFLAGS="${CXXFLAGS} -O2 -DNDEBUG"
if test "${GXX}" = "yes" ; then
CXXFLAGS="${CXXFLAGS} -Wuninitialized -ffast-math -finline-functions
-fomit-frame-pointer -fexpensive-optimizations"
fi
fi
pgpJBFXzj0snF.pgp
Description: PGP signature
