Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
> > What's "nonstandard" about our system is the fact that you have to
> > re-run *autogen.sh* (or gen-make.py) when new C files are added.
> > Nobody suspects that. It's quite weird. It bites people constantly.
> > If I had a nickel for every dev-list post...!
> >
> > Please remind me why our system is so much better than the norm? :-)
>
> Now, let's be fair :-). The system is a lot better than the norm in
> many respects...
Oh, definitely. It's quite flexible. I really like being able to
edit build.conf. The system, overall, is way cool. I'm just not
happy with this one certain aspect.
> Even in this respect, if you consider the usual alternative: many
> systems require developers to remember to update a statically
> maintained list whenever they add a new C file.
Which is the norm. It's the difference between *one* developer having
to remember to augment a static list, vs. *all* developers having to
remember to re-run their generators. I don't like the burden being
spread out like that... it doesn't make sense to me. People already
run "./configure; make" all the time. I'm tired of teaching newbies
about the non-standard "gen-make.py build.conf; ./configure; make"
sequence.
> Our system generates that list automatically, [...]
...which feels a tad sloppy. If I copy a temporary .c file into the
working copy, I'd hate to see it accidentally picked up by the build
scanner.
Step back for a second. Here have this nice system with a beautiful
.conf file that allows you to be specific about *so* many behaviors,
and yet this system *doesn't* have inherent knowledge about what files
to compile for any given thing. Doesn't that strike you as odd?
> Both ways are error prone, but at least our way you don't have to go
> crawling over the logs to figure out how to update the list when
> something goes wrong.
Actually, I don't think this is a realistic fear. I don't see how a
developer could add a new C file and forget to edit the static list;
otherwise the developer would never be able to compile at all. And we
all know that while perhaps we don't always run 'make check' before
each commit, we all *do* compile our changes first. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 18:56:28 2002