comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Project files ads/adb organization
Date: Thu, 15 Dec 2016 22:31:40 +0200
Date: 2016-12-15T22:31:40+02:00	[thread overview]
Message-ID: <ebgctdF9g4cU1@mid.individual.net> (raw)
In-Reply-To: <o2u9tf$9j0$1@dont-email.me>

On 16-12-15 16:40 , Alejandro R. Mosteo wrote:
> I'm overthinking how to organize a library source and have come to this
> idea (Gnat-specific due to ads/adb files):
>
> - An /spec/ folder with ads files exposing the client interface.
> - An /priv/ folder with ads files for support packages, not intended for
> direct client use.
> - A /body/ folder for all the bodies.
>
> A variant could be to separate public spec from bodies, but keep private
> parts together.
>
> I wonder if the idea of separating specs from their bodies could be seen
> as a poor choice. Certainly it requires developers to use an Ada-aware
> editor like GPS, but for clients seems appropriate not to mix things
> they don't need to see.
>
> Opinions? Or "whatever floats your boat?"

I don't see any benefit in separating declarations from bodies "on 
principle". For me to do that, there would have to be some other reason 
for such a separation.

I tend to put all sources (.ads and .adb) in one and the same folder, to 
be able to "grep" and use other command-line tools easily.

I use folders for the following purposes:

- separating more or less independent source-code sets, for example 
different programs (executables) which share some code (common folder), 
but also have some program-specific code (program-specific folders)

- separating different versions of packages, for example a package with 
a portable, standard declaration in one folder, but specific bodies for 
Linux and Windows, in separate "linux" and "windows" folders, with 
different GPR files or build scripts to select the versions for a 
particular build.

Some of my colleagues like to divide application source code into 
folders according to the functional divions of the application, for 
emxaple a "user interface" folder, a "database interface" folder, a 
"computations" folder, and so on. I prefer not to do that, but to rely 
on the package hierarchy or other package-and-file naming conventions to 
group files according to function.

So whatever floats...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .


  reply	other threads:[~2016-12-15 20:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-15 14:40 Project files ads/adb organization Alejandro R. Mosteo
2016-12-15 20:31 ` Niklas Holsti [this message]
2016-12-15 22:30 ` Randy Brukardt
2016-12-16 12:46 ` Alejandro R. Mosteo
2016-12-16 14:48 ` Egil H H
2016-12-19  9:40   ` Alejandro R. Mosteo
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox