GPR: project hierarchy and file names

GPR: project hierarchy and file names

[Yannick Duchêne (Hibou57)]

I wanted to attempt to try something seducing to me: using project  
hierarchy matching packages hierarchy, but with tricky part, as much  
seducing to me, which is to use only to inner package name as the file  
name.

Let me explain, and just imagine there are more files than the following  
example shows.

Let

    Application
    Models
    Models.Object1
    Models.Object2
    Views
    Views.Object1
    Views.Object2

be some package. The common way to name these would be (just to give spec  
file names, would be the same for body)

    application.ads
    models.ads
    models-object1.ads
    models-object2.ads
    views.ads
    views-object1.ads
    views-object2.ads

The seducing idea I wanted to attempt is the following.


Have a directory hierarchy like this

    application
       models
       views


each ones holding their packages, just with shorten file names (using only  
the inner name)

    application
       |- application.ads
       |
       +- models
       |    |- object1.ads
       |    |- object2.ads
       |
       +- views
            |- object1.ads
            |- object2.ads



then, for each, a project file

    application
       |- application.gpr
       |- application.ads
       |
       +- models
       |    |- models.gpr
       |    |- object1.ads
       |    |- object2.ads
       |
       +- views
            |- views.gpr
            |- object1.ads
            |- object2.ads


(the real case hierarchy ranges from 1 to 4 levels)

I followed this step:

    * Created the directory hierarchy
    * Dispatched files to directories depending on their
      position in the packages hierarchy
    * Renamed files to remove the package hierarchy path
      prefix and just keep the proper package name for
      file names (obviously, the source style says
      “package Parent.Child is” for an example)
    * Created the GPR project files files with
      a simple “for Source_Dirs use (".");”
    * Added a With clause for the parent project
      in each child project (like “with "../application.gpr";”
      in both models.gpr and views.gpr)
    * Added a Limited With clause for each subproject in
      parent projects (there is only one in the example:
      “limited with "models/models.gpr";” and
      “limited with "views/views.gpr";” in
      application.gpr);


This was looking fine for me except it seems I got clashes. Let go to the  
GNAT documentation a moment.

http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_12.html#SEC132
It says, about the project manager:

  <<
    One very important aspect of a project hierarchy is that a
    given source can only belong to one project (otherwise the
    project manager would not know which settings apply to it and when
    to recompile it). It means that different project files do not usually
    share source directories or when they do, they need to specify
    precisely which project owns which sources using attribute Source_Files
    or equivalent. By contrast, 2 projects can each own a source with the
    same base file name as long as they live in different directories.
  >>


When it says that a given source must only belongs to a single project, if  
does not mention directly or indirectly nor it does mention With vs  
Limited With. At least, when a project A import a project B which imports  
a project C, then files of C can be used in both A and B. So I suppose I  
have to understand “source can only directly belong to one project”. And  
it days two projects can own files with same base name, as long are they  
are not in the same directory (obvious).

So the above should be OK, but it fails.

When I open any project in a similar hierarchy, I got tons of  
red-highlighted message from GPS, which talks about units which can belong  
to only one project. It seems to be related to base file name, as if I (in  
the context of the above example) rename object1.ads so that they both  
have a different name in the Views and Models directories, there is no  
more error message about object1 unit.


Well, this kind of organization is not formally required, this is just I  
feel it nice, and it is ever possible to make it successed (or something  
similar), I would like to use this one (would ease view of sibling  
hierarchies dependencies, as well as handy in GPS and in any GUI file  
system explorer).


Is this layout or similar, feasible with GPR project files or it is a  
totally excluded idea ?

Note: I wanted to try to use gnatname and Naming package (in GPR files),  
but this does allow directories, it works only with base names.

Re: GPR: project hierarchy and file names

[Dmitry A. Kazakov]

On Thu, 19 Aug 2010 05:23:47 +0200, Yannick Duch�ne (Hibou57) wrote:

> each ones holding their packages, just with shorten file names (using only  
> the inner name)
> 
>     application
>        |- application.ads
>        |
>        +- models
>        |    |- object1.ads
>        |    |- object2.ads
>        |
>        +- views
>             |- object1.ads
>             |- object2.ads

This cannot work just because you have two units named object1. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GPR: project hierarchy and file names

[Yannick Duchêne (Hibou57)]

Le Thu, 19 Aug 2010 09:03:25 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>
> This cannot work just because you have two units named object1.
>
I did not want to gave up, but I finally had to conclude the same. No  
workaround.
I will try to play with gnatkr (alias GNAT Krunch) or I will get another  
idea.
Using gnatname appears to not be handy, at least because it implies  
maintenance and also because it create Naming package which conflict with  
the ones specified in share/gprconfig files.

Also a funny thing: gnatname produce secondary project files (for the  
Naming package), and when there is more than one GPR file in a directory,  
GPS cannot open the project file and always load the default project  
instead (at least on Windows, do not know for others).

Re: GPR: project hierarchy and file names

[Pascal Obry]

Yannick,

> Also a funny thing: gnatname produce secondary project files (for the
> Naming package), and when there is more than one GPR file in a
> directory, GPS cannot open the project file and always load the default
> project instead (at least on Windows, do not know for others).

Because you have probably disabled the initial dialog which present
three options (from memory):
   - use default project
   - load a given project
   - create a new project

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: GPR: project hierarchy and file names

[Dmitry A. Kazakov]

On Thu, 19 Aug 2010 09:31:35 +0200, Pascal Obry wrote:

>> Also a funny thing: gnatname produce secondary project files (for the
>> Naming package), and when there is more than one GPR file in a
>> directory, GPS cannot open the project file and always load the default
>> project instead (at least on Windows, do not know for others).
> 
> Because you have probably disabled the initial dialog which present
> three options (from memory):
>    - use default project
>    - load a given project
>    - create a new project

No, this happens when you click on a gpr-file which has errors. GPS creates
a default project (I have no idea what for). The project is deleted by GPS
when you exit it.

GPS has many funny glitches. E.g. when you open GPS in the server mode it
opens an empty project instead of the requested one. You have to reload
your project again.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GPR: project hierarchy and file names

[Yannick Duchêne (Hibou57)]

Le Thu, 19 Aug 2010 09:42:36 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> No, this happens when you click on a gpr-file which has errors. GPS  
> creates
> a default project (I have no idea what for). The project is deleted by  
> GPS
> when you exit it.
There is even no need for any error. Just try to create two project files  
in the same directory, and you will see. Example: go in <prefix>/lib/gnat  
(there are typically multiple project there). Click on a project, it will  
open the project file in the editor, but will load the default project  
instead. No need for any error.

> GPS has many funny glitches.
Yes, and we love it for its glitches (it make it touching)

Re: GPR: project hierarchy and file names

[Dmitry A. Kazakov]

On Thu, 19 Aug 2010 09:20:45 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 19 Aug 2010 09:03:25 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>
>> This cannot work just because you have two units named object1.
>>
> I did not want to gave up, but I finally had to conclude the same. No  
> workaround.

There is no need for workarounds. What could be done is a very simple
thing. The GPS project view is a GtkTreeView. It is built in the MVC model.
So it is relatively simple to change the way it shows child and separate
units. Instead of:

   A.ads
   A-B.ads
   A-C.ads

at the same level, this

   A.ads
      B.ads
      C.ads

Since any child has a parent, it is always possible to do. They probably
have a GtkTreeStore for the project files. It would be enough to add a new
column for stripped names or else cell-data callback. Not much work, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GPR: project hierarchy and file names

[Yannick Duchêne (Hibou57)]

Le Thu, 19 Aug 2010 09:50:39 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>    A.ads
>    A-B.ads
>    A-C.ads
>
> at the same level, this
>
>    A.ads
>       B.ads
>       C.ads
I though about it too, that was even the first idea, but as I know this  
tree view is not a Python plugins, and as I am not feeling OK to patch GPS  
sources... Well, will search and see if there is ever a way to hook  
something from Python.

Hep, I also noticed that when you specify a source directory and state  
subdirectories should be also used, the project tree view does not display  
subdirectory as subtrees, and always displays subdirectory as as-many  
paths, even when “Flat View” is unchecked.

Re: GPR: project hierarchy and file names

[Dmitry A. Kazakov]

On Thu, 19 Aug 2010 10:41:25 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 19 Aug 2010 09:50:39 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>>    A.ads
>>    A-B.ads
>>    A-C.ads
>>
>> at the same level, this
>>
>>    A.ads
>>       B.ads
>>       C.ads

> I though about it too, that was even the first idea, but as I know this  
> tree view is not a Python plugins, and as I am not feeling OK to patch GPS  
> sources... Well, will search and see if there is ever a way to hook  
> something from Python.

You could post a proposal to AdaCore.

> Hep, I also noticed that when you specify a source directory and state  
> subdirectories should be also used, the project tree view does not display  
> subdirectory as subtrees, and always displays subdirectory as as-many  
> paths, even when “Flat View” is unchecked.

This is a good feature IMO. To have it otherwise, I do this:

   for Source_Dirs use ( <explicit directories> );
   for Source_Files use ( <simple file names from the directories above> );

This shows the directories in the view.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: GPR: project hierarchy and file names

[Yannick Duchêne (Hibou57)]

Le Thu, 19 Aug 2010 05:23:47 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:

Tip about foreign object files.

An interesting detail I've noticed while trying to setup this project  
hierarchy: it seems using “pragma Linker_Options ("...")” is not the best  
thing to do, not resilient. Until now I always did this way to link to  
foreign object files, but this was not working anymore, because building  
 from the topmost project, at link stage, GCC was unable to find these  
object files (which was not automatically moved as I first supposed).

Better place it in a library linker options (and turn the project into a  
library).

I may guess it work like this: with a Linker_Options given as a pragma in  
a source file, the linked object file path is relative to the topmost  
project, whatever is the location of the source file containing the  
Linker_Options pragma; while with a linker option given in a project file,  
it is always relative to the original project file. The latter is neatly  
easier to handle.