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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.50.114.2 with SMTP id jc2mr10942009igb.5.1442836981132; Mon, 21 Sep 2015 05:03:01 -0700 (PDT) X-Received: by 10.182.221.133 with SMTP id qe5mr76863obc.6.1442836981105; Mon, 21 Sep 2015 05:03:01 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!kq10no6045497igb.0!news-out.google.com!f6ni11511igi.0!nntp.google.com!kq10no6045486igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 21 Sep 2015 05:03:00 -0700 (PDT) In-Reply-To: <428ab038-94ac-4549-ae3b-0b06f4fb80a8@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.138.39.55; posting-account=IcHmbgoAAABVfpbjrkJyy4Yb3hmce3tn NNTP-Posting-Host: 194.138.39.55 References: <428ab038-94ac-4549-ae3b-0b06f4fb80a8@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: How to best organize and build large projects? From: Lucas Redding Injection-Date: Mon, 21 Sep 2015 12:03:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:27798 Date: 2015-09-21T05:03:00-07:00 List-Id: On Sunday, September 20, 2015 at 5:42:44 PM UTC+1, John Smith wrote: > Hi all, >=20 > In your experience, what are some good approaches in case I want to organ= ize and then build an application with many files and resources. Would you= split the project up into source, resources, build_scripts, etc? Would yo= u use makefiles to build the whole thing or some other tool? In my humble opinion it is always good to break down your product/system: Create subsystems, within the subsystem create products, and within product= s create classes/Ada packages depending on the size/distribution of the app= lication. My example below talks about a very large application. Manage your products/classes/subsystems and system (Main build) in a hierar= chy (nesting) of self contained/independent libraries using gpr with possib= ly a single build script per GPR whether you decide to use gprbuild/gnatmak= e/make etc it can be independent to the gpr. Each subsystem/product/package needs to be as self contained/independent as= possible; i.e. compiles into a libary which is reused within the hierarchy= , or compiles into an executable application. This aids the design/developm= ent, maintenance, verification down the line. This way you can distribute t= he development of the system to separate teams each responsible for a subsy= stem/product/package. A little effort upfront to design your system as such= saves a huge amount of effort down the line. Bottom up as well, look to maintaining single units, down to separates. Aga= in, you have individual control down to the lowest common denominator ; i.e= . if a separate changes, no need to impact the rest of the package, and a r= ecompile is quick. There is no silver bullet so all the above may be good but you may want to = balance it due to the nature of your project. For instance disregard the se= parates because you dont' need the bottom up control etc. Hope that helps