[jum@ans.helios.de: Proposal: changes to the binbuild.sh script]

[Jens-Uwe Mager <ju...@helios.de>]

Here my proposal again. There two other points that have been brought up
that appear to be interesting:

* Do not ship the source at all, just ship the binaries. Good idea, but
  then the binary tar ball should be totally different, it should
  probably mirror a /usr/local/apache directory with just one script to
  copy over things, preserving what is already there for upgrades.

* Integration of the binary build into the standard Apache makefiles.
  This is probably the way to go, but I would believe this would be for
  the next release due to the changes necessary.

Both approaches could be combined by a new rule in the makefiles so one
could do a "make bindist" and it would build the directory structure
for the binary tar ball just containg what is supposed to be in
/usr/local/apache plus an install script.

----- Forwarded message from Jens-Uwe Mager <ju...@ans.helios.de> -----

Message-ID: <19...@ans.helios.de>
Date: Sun, 20 Sep 1998 17:53:58 +0200
From: Jens-Uwe Mager <ju...@ans.helios.de>
To: new-httpd@apache.org
Subject: Proposal: changes to the binbuild.sh script
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Status: RO
Content-Length: 2805
Lines: 84

While doing a few binary builds, I have found it to be rather difficult
to install the resulting distribution. I think this is rather paradox,
as a binary distribution is supposed to skip all the complexities users
without developer experiences face. I would like to propose the
following patch to the binbuild.sh utility that makes a few thing
easier.

* It does use the APACI and it configures most of the modules as
  shared. This gives users maximum flexibility by being able to load at
  runtime what they need. These who object to loadable modules and opt
  for a statically linked all-in-one httpd probably will compile it
  themselves anyways.

* It saves the output of a dry (make -n) install run under
  binbuild-install. This file is usable as input to the shell and
  produces an installed apache from the binary tar ball as a make
  install would have done.

* It does not move the httpd any more nor does it make clean to be able
  to run the install process cleanly. This does result in larger tar
  balls, though.

Comments anyone?

--- binbuild.sh.orig	Sun Sep 20 16:11:36 1998
+++ binbuild.sh	Sun Sep 20 17:27:02 1998
@@ -31,8 +31,10 @@
 # directory that it is untarred into
 release=apache_1.3.1
 dir=$release
-# conf is the Configuration file that you wish to use to build httpd
-conf=Configuration
+# arguments for the APCI configuration, do build most of the
+# modules as shared modules, this is most useful for binary
+# distributions.
+conf="--enable-module=most --enable-shared=max"
 # gzcat should be set to something that will take a .tar.gz as an 
 # argument and send the uncompressed .tar to stdout.  On some systems,
 # it will be zcat
@@ -55,25 +57,18 @@
 # particularily nice names but because it is easy
 system=`./$release/src/helpers/GuessOS | sed 's/\//_/g'` || exit 1
 
-cd $dir/src || exit 1
-echo running Configure
-./Configure || exit 1
+cd $dir || exit 1
+echo running configure
+./configure $conf || exit 1
 echo attempting to make httpd
-make 2>&1 | tee ../../make.out-$system
-if [ ! -f httpd ] ; then
+make 2>&1 | tee ../make.out-$system
+if [ ! -f src/httpd ] ; then
     echo error: httpd binary not made
     exit 1
 fi
-echo making binaries in support
-cd ./support || exit 1
-# no, we don't make suexec or worry too much about errors here
-# Marc is lazy.
-make
+echo make succeeded, saving install rules
+make --no-print-directory -n install | sed -e 's/make/:/' >binbuild-install
 cd .. || exit 1
-echo make succeeded, saving the binary and doing a make clean
-mv httpd httpd-$system
-make clean || exit 1
-cd ../.. || exit 1
 
 echo creating tar file
 tar cf - $release > $release-$system.tar || exit 1

--
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	jum@helios.de

----- End forwarded message -----

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	jum@helios.de

Re: [jum@ans.helios.de: Proposal: changes to the binbuild.sh script]

[Ben Hyde <bh...@pobox.com>]

The binary tar ball issue got a lot of discussion
back in june 98.  A number of people carefully
enumerated issues with the binary tarballs that
would need to be worked thru.  If one goes thru
the archive looking for "binary" you'll see most
of them.  These are important valid points that
rain on the parade of Ralf's constructive work to
make this a reality.  (My thoughts for example are
there in <98...@gensym1.gensym.com>)

We did not shake out any of the issues raised
there.

This is a good example of "how tight a lid on
1.3.*" issue.  My sense is that the consensus is
that we should move most of our resources to 2.0.

  - ben hyde

Re: [jum@ans.helios.de: Proposal: changes to the binbuild.sh script]

[Jens-Uwe Mager <ju...@helios.de>]

On Wed, Sep 23, 1998 at 02:17:19PM -0700, Roy T. Fielding wrote:
> More economic for whom?  It results in a larger download, but then
> we don't have to answer questions about where to get the source and
> we don't have to worry about finding the source two years from now
> when someone wants to see it.

More economic for downloads. I would suspect that most bug reports
will/are correlated by version number and the known history of that
version. Or did the Apache developers indeed request from a bug report
submitter the source of his binary tar ball in the past?

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	jum@helios.de

Re: [jum@ans.helios.de: Proposal: changes to the binbuild.sh script]

[Jens-Uwe Mager <ju...@helios.de>]

On Wed, Sep 23, 1998 at 12:47:08PM -0700, Roy T. Fielding wrote:

> I don't like the idea of shipping the binary without the source.
> It serves as an important record and documentation of what went into
> the binary, even if the person who downloads it never looks at it
> themself.  Since we don't keep a copy of every version distributed,
> we need to send the source with the binary.

Hmm, isn't it more economic to just keep the one source tar archive
instead of putting it into each binary tar?
-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	jum@helios.de