From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: nigel@access4.digex.net (Nigel Tzeng) Subject: Re: Software Development Environments (Was: What is wrong with OO ?) Date: 1997/01/03 Message-ID: <5ak1pm$gfm@access4.digex.net>#1/1 X-Deja-AN: 207562835 references: <5a9r1k$e74@news4.digex.net> <32C88BE0.7F2B@acm.org> <32CD3495.14FE@pc-plus.de> organization: Express Access Online Communications, Greenbelt, MD USA newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-03T00:00:00+00:00 List-Id: In article <32CD3495.14FE@pc-plus.de>, Stephen Riehm wrote: >Robert C. Martin wrote: [snip] >the principle being that the sum of many parts is much greater than >could ever be achieved by one whole. Robert's dream could be achieved >if the parts (compiler, editor, build system, debugger etc) could be >made to really fit together. Someone here said that this "isn't rocket >science", and he's right. It just takes a little logical thinking. It is really too bad that CenterLine is out of the C++ IDE market because they had a great little product called CLIPC (Centerline Interprocess Communication) that is effectively a "software bus" where third party products can be "plug and play" with the core product. It it similar to ToolTalk but ran a lot faster with a much simpler interface. I assume that the original plan was to publish the messages that ObjectCenter used and allow any third party to develop an editor, debugger, or whatever and replace ObjectCenter components. It's too bad that ToolTalk never gained mass acceptance since it is free on most platforms (unlike CORBA) and would do the job. Of course this is the same industry that opted for DCE RPC instead of the widely used and freely available ONC RPC. [snip] >Another big help would be, in my view, the teaching of deterministic >development practices. Unfortunately I am yet to have found ANY >definitive work in this area, although some people are beginning to >see the relevance. I can best describe this with examples of what NOT >to do, but I am desperately searching for a mechanism to help improve >the situation. I would think that SEI and PSP would fall into this category. I think that if you are an SEI level 3+ software house then your development process is fairly well documented and hopefully adhered to. I suppose this is about as "deterministic" as one gets. [snip] >In the classic "make" environment, all files must be in the current >directory. A good enhancement of this is the introduction of gmake's >VPATH, where files can be found elsewhere, ie: in a central >repository, but in order to work out what is going to be done by make, >you need to be nothing short of a genius (OK, the rules are simple >enough, but if I had a cent for each time some one asked my "why did >make do that?" I would be a very rich man indeed). The next >improvement is to centralise the rules used for generating code. This >"can be achieved" via included makefiles, but there is still lots of >room for improvement. Um...we have a mulitplatform project based on a central CVS repository using fairly simple makefiles (and gmake). I'm certainly no Make guru but we came up with it in an afternoon. It correctly finds the right include files and libraries from your local development directory or the integration area or the release area using VPATH and -L. It correctly builds to the right object, library and binary areas. On a previous project we did use included makefiles but we didn't get that fancy this time around. [snip] >So, my point is, that the language is a key factor when considering >I would like to hear your comments about production environments, >should shadow trees be used to provide simple access to a central >software repository? what about using hard or soft links? How do you >coordinate the work of 50+ developers all working on the same >project? Be careful with soft links. At one time we had an explosion of links and a corresponding explosion of confusion. I think that we have 2 left... beta which links to the current integration area and release that points to the latest released tree. Then we release the current version we repoint release to the current beta tree and create a new tree. The old release tree gets moved offline. before: beta -> v2.3 release -> v2.2 after: beta -> v2.4 release -> v2.3 >If anyone knows of any seminars, documents, research papers, web sites >etc etc that address these problems, I would be most grateful to hear >from you. There are a couple of web sites that have some "best practices" info and a host of books on the topic. I tend to suggest buying Yourdon's book simply to get his recommended reading list and he is an easy read on the topic. There is also a cm newsgroup that talks about a lot of CM tools (and bugs with CM tools...) [snip] > >Steve Nigel