Xref: news-dnh.mv.net comp.os.msdos.djgpp:2605 Path: news-dnh.mv.net!mv!news.sprintlink.net!EU.net!Germany.EU.net!news.dfn.de!scsing.switch.ch!swidir.switch.ch!in2p3.fr!univ-lyon1.fr!jussieu.fr!oleane!simtel!chi-news.cic.net!news.uoregon.edu!waikato!comp.vuw.ac.nz!tao.sans.vuw.ac.nz!empty From: empty AT sans DOT vuw DOT ac DOT nz (Malcolm Taylor) Newsgroups: comp.os.msdos.djgpp Subject: Re: Many small files versus big clusters Date: 13 Oct 1995 00:06:00 GMT Organization: SANS, Student Access Network System Lines: 28 References: <45lrss$7lg_001 AT midland DOT co DOT nz> Nntp-Posting-Host: tao.sans.vuw.ac.nz To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp Chris McFarlane (chrismac AT midland DOT co DOT nz) wrote: : A novel and interesting idea, worthy of further consideration. : How do you view handling the advantages of modular development ? : If multiple files are concatenated, then surely the editor must load : everything to edit one subfile, slowing down the performance. : Sharing development amongst a number of contributors gets difficult to : coordinate; requiring merging under a concatenated module scheme. : When recompiling, perhaps the entire file will need recompilation, rather than : just a subfile as at present; exit the make system advantages. : For completed code, undergoing minimal changes, perhaps these aspects aren't a : significant disadvantage ? How do you view these needs ? This sort of thing could be done with no change in the binaries of the compiler. C has the preprocessor directive #ifdef and you could simply have the makefile define say __LIBRARY_UNIT_1__ for the first unit, etc. and it will not take much longer to compile than your small file. To solve the distributed development you'd just make the modules of files that each person is developing. You don't have to reduce all files in a directory to 1 file, you can just reduce 100 to 5 and that would significantly reduce the problem. Malcolm PS this could easily be done by hand. : Chris