This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Code Bloat g++
- To: mark at codesourcery dot com (Mark Mitchell)
- Subject: Re: Code Bloat g++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Tue, 22 Feb 2000 20:21:04 -0800 (PST)
- Cc: mrs at windriver dot com, gcc at gcc dot gnu dot org, per at bothner dot com
> Mike> You have an along side database
Mark Mitchell writes:
> Oh, boy, I can hear the sounds of matches being applied to kindling.
> There are lots of people who love program databases and just as many
> who hate them.
The haters are usually those who have pulled out all of their hair trying
to get a development process to work in the presence of such databases
(death to cfront-style template repositories!). Usually there are
problems with parallel makes, or if these problems are addressed, problems
with locking (my nice 8-processor compute server slows to a crawl because
compiles can't run until they acquire a global lock), or wierd time-based
stuff which is just different enough from the rules of make to make it
impossible to write correct makefiles, or the needs of reusable libraries
aren't carefully considered.
So, I'm open to database proposals, but only if they withstand some
extremely tough criticism. Hacks won't do. But if done right, it would
seem that the C++ development process could be made much faster.
Currently if I make a small change in an important header the world
recompiles. Given a compilation system that understands that I only added
a private member function to a class, it could determine that only one
file needs to recompile (if it uses explicit files at all; it could simply
compile the implementation of that member). But such a radical change
can't be just slightly better to get adopted; it has to be a clear enough
win to get people to change the whole way they do development, which is a
big price to pay.