Re: Project files (Was: Should Inline be private in the private part of a package spec?)

["Randy Brukardt" <randy@rrsoftware.com>]

"Jacob Sparre Andersen" <sparre@nbi.dk> 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.