Project files ads/adb organization

Project files ads/adb organization

[Alejandro R. Mosteo]

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?"

Cheers,
Álex.

Re: Project files ads/adb organization

[Niklas Holsti]

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
       .      @       .

Re: Project files ads/adb organization

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:o2u9tf$9j0$1@dont-email.me...
> 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 think its necessarily "overthinking". For the Janus/Ada runtime, we 
only provide the specifications in the non-embedded packages (don't support 
recompiling the runtime for those). Usually, that's all you need.

For Claw, we just provided it in one bunch, but there aren't very many 
private packages, so almost every .ads is a public specification.

I'd suggest not making it too complicated, but  some sort of separation of 
"public" stuff that clients are supposed to use, and the rest of it, seems 
reasonable.

                          Randy.

Re: Project files ads/adb organization

[Alejandro R. Mosteo]

On 15/12/16 15: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):

> Opinions? Or "whatever floats your boat?"

Thanks Niklas and Randy for your opinions.

>
> Cheers,
> Álex.

Re: Project files ads/adb organization

[Egil H H]

On Thursday, December 15, 2016 at 3:40:04 PM UTC+1, Alejandro R. Mosteo wrote:
> 
Since you're already using Gnat, have you looked at GPRInstall?
It will allow you to expose only API-specs in the install dir for library projects


-- 
~egilhh

Re: Project files ads/adb organization

[Alejandro R. Mosteo]

On 16/12/16 15:48, Egil H H wrote:
> On Thursday, December 15, 2016 at 3:40:04 PM UTC+1, Alejandro R. Mosteo wrote:
>>
> Since you're already using Gnat, have you looked at GPRInstall?
> It will allow you to expose only API-specs in the install dir for library projects

Thanks for the pointer, I will keep it in mind for installation scripts. 
At this time I am more concerned with github-like distribution only.