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.6 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48 autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.236.133.242 with SMTP id q78mr11243941yhi.11.1344998913331; Tue, 14 Aug 2012 19:48:33 -0700 (PDT) MIME-Version: 1.0 Path: c6ni115589900qas.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin2!goblin.stu.neva.ru!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Project files (Was: Should Inline be private in the private part of a package spec?) Date: Mon, 13 Aug 2012 17:12:36 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net><50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net><502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net><50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com> <87zk5zngnc.fsf_-_@adaheads.sparre-andersen.dk> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1344895962 22033 69.95.181.76 (13 Aug 2012 22:12:42 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 13 Aug 2012 22:12:42 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-08-13T17:12:36-05:00 List-Id: "Jacob Sparre Andersen" wrote in message news:87zk5zngnc.fsf_-_@adaheads.sparre-andersen.dk... > Randy Brukardt wrote: > >> (The recompilation time they would save with shared files is probably >> less than the time that they would spend on managing the projects.) > > We don't use project files to save compilation time. We do it to: > > a) reuse shared libraries The customers I was referring to simply make copies of the shared files. My understanding is they had a strong process about modifying them, and a simple way to refresh those copies when needed. > b) direct the compiler at the proper target-specific package bodies I haven't talked about this, but it would be the same. >> YMMV, of course, but I think "one-button builds" from raw (and >> portable) source code is the ideal way to go. > > Agreed. > >> I'm now looking at ways to make that easier with Janus/Ada (one >> obvious way is to eliminate the need for any special naming >> conventions for Ada source code). > > How would you handle multiple available bodies for the same package? (I > imagine it would turn it into at least a "two-button build".) My presumption is that every target would have a separate copy of the source code, with the appropriate bodies. That copy would be refreshed from the version control as needed (and that's outside of what Janus/Ada is concerned about). One hopes that the version control has an easy way to get shared files and separate bodies easily. (That's the main reason that we built our own front-end to CVS; to me, a project is a web of shared files (including specifications) and unshared bodies; we needed a way to get all of the files for, say, an MS-DOS target and we needed to be able to develop all of those targets at one time. Conventional branching is just too ad-hoc and too hard to use for that, because you have a whole series of files with bodies specifically for different targets (and all of which need to be updated in parallel). Anyway, there are a lot of ways to do this sort of thing, and its doubtful that one size would fit all (or even many). Randy.