You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/07 17:35:47 UTC
make depend.
I have brought this up before, and it was shot down before, but I'm trying
again. Is there a reason we don't have the dependancies in CVS for
2.0? Currently, as soon as we extract from CVS we have to do a make
depend or else the code doesn't understand any dependancies.
This is not the way things were in 1.3, and it is a PITA.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: make depend.
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
> > - avoids maintenance overhead
>
> I don't think it is a high overhead. Once in a while, run make depend;cvs
> commit on a new tree. We could automate that if we really needed
> to. This was never an issue for 1.3
This is what we do for OpenSSL. It works fine.
> > - allows clean/separate storage of dependencies in the
> > build directory
>
> Why can't we leave the dependencies in the build directory and have them
> committed to CVS. Where we store the dependencies should have nothing to
> do with wether they are in CVS or not.
>
> > Cons:
> >
> > - developers need to run 'make depend' once
>
> - It gives users a false sense of security when compiling
> code. Code can be changed and not re-compiled.
Users can have a set of dependencies - that's an orthogonal issue - we
just create it before creating a distribution.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: make depend.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jul 07, 2000 at 07:49:02PM +0200, Sascha Schumann wrote:
> On Fri, 7 Jul 2000 rbb@covalent.net wrote:
>...
> > > - avoids maintenance overhead
> >
> > I don't think it is a high overhead. Once in a while, run make depend;cvs
> > commit on a new tree. We could automate that if we really needed
> > to. This was never an issue for 1.3
>
> I don't see the point of storing anything in the CVS which
> can be easily regenerated.
I'm with Sascha on this one. We made a call a while back to *not* include
generated output in our CVS tree. The dependencies are one of those, so they
can/should stay out of the tree.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: make depend.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 7 Jul 2000 rbb@covalent.net wrote:
>
> > > I have brought this up before, and it was shot down before, but I'm trying
> > > again. Is there a reason we don't have the dependancies in CVS for
> > > 2.0? Currently, as soon as we extract from CVS we have to do a make
> > > depend or else the code doesn't understand any dependancies.
> >
> > That is also the case with other large projects, like
> > XFree86, the Linux kernel and OpenLDAP (just to name a few).
>
> Does FreeBSD do it this way? I don't think it does. but I could be
> wrong.
It has a separate depend target.
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/share/mk/bsd.dep.mk?rev=1.2.4.3
Dito for NetBSD.
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/sharesrc/share/mk/bsd.dep.mk?rev=1.30
And OpenBSD.
http://www.openbsd.org/cgi-bin/cvsweb/src/share/mk/bsd.dep.mk?rev=1.4
They seem to use a common target `dependall' which causes a
recursive generation of dependencies.
> > The advantages of this method are:
> >
> > - users who compile once don't need dependencies anyway
>
> This is a fallacy. If somebody applies even one patch, they need the
> dependancies. Ever notice that the first thing the Linux Kernel tells you
> to do before you build is run make depend? This is because if you change
> anything in the code, the dependancies are necessary.
Well, so tell them to run make depend as well.
> > - avoids maintenance overhead
>
> I don't think it is a high overhead. Once in a while, run make depend;cvs
> commit on a new tree. We could automate that if we really needed
> to. This was never an issue for 1.3
I don't see the point of storing anything in the CVS which
can be easily regenerated.
> > - allows clean/separate storage of dependencies in the
> > build directory
>
> Why can't we leave the dependencies in the build directory and have them
> committed to CVS. Where we store the dependencies should have nothing to
> do with wether they are in CVS or not.
See above. There is another technical issues which could
probably be solved by feeding the output of the dependency
generator through sed (similar as it is done in APR).
> > Cons:
> >
> > - developers need to run 'make depend' once
>
> - It gives users a false sense of security when compiling
> code. Code can be changed and not re-compiled.
Educating users is the Right Way. We probably don't want
ignorant users.
> I disagree with many of your advantages to this style.
Good.. the world would be boring, if everybody would agree
with me.
- Sascha
Re: make depend.
Posted by rb...@covalent.net.
> > I have brought this up before, and it was shot down before, but I'm trying
> > again. Is there a reason we don't have the dependancies in CVS for
> > 2.0? Currently, as soon as we extract from CVS we have to do a make
> > depend or else the code doesn't understand any dependancies.
>
> That is also the case with other large projects, like
> XFree86, the Linux kernel and OpenLDAP (just to name a few).
Does FreeBSD do it this way? I don't think it does. but I could be
wrong.
> The advantages of this method are:
>
> - users who compile once don't need dependencies anyway
This is a fallacy. If somebody applies even one patch, they need the
dependancies. Ever notice that the first thing the Linux Kernel tells you
to do before you build is run make depend? This is because if you change
anything in the code, the dependancies are necessary.
> - avoids maintenance overhead
I don't think it is a high overhead. Once in a while, run make depend;cvs
commit on a new tree. We could automate that if we really needed
to. This was never an issue for 1.3
> - allows clean/separate storage of dependencies in the
> build directory
Why can't we leave the dependencies in the build directory and have them
committed to CVS. Where we store the dependencies should have nothing to
do with wether they are in CVS or not.
> Cons:
>
> - developers need to run 'make depend' once
- It gives users a false sense of security when compiling
code. Code can be changed and not re-compiled.
I disagree with many of your advantages to this style.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: make depend.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 7 Jul 2000 rbb@covalent.net wrote:
>
> I have brought this up before, and it was shot down before, but I'm trying
> again. Is there a reason we don't have the dependancies in CVS for
> 2.0? Currently, as soon as we extract from CVS we have to do a make
> depend or else the code doesn't understand any dependancies.
That is also the case with other large projects, like
XFree86, the Linux kernel and OpenLDAP (just to name a few).
The advantages of this method are:
- users who compile once don't need dependencies anyway
- avoids maintenance overhead
- allows clean/separate storage of dependencies in the
build directory
Cons:
- developers need to run 'make depend' once
It might be possible to eliminate the disadvantage by
optionally using a method similar to automake's automatic
dependency tracking, but I haven't analyzed that yet (AFAIR
it relies on GNU make).
- Sascha