This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Code Bloat g++



>     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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]