Dependency [not finding project file]

[Hubilari]

Hello,
installing gnoga with Alire, meaning "$ alr get --build gnoga", (following $ alr run & $ alr with gnoga), compilation failed finding components.gpr.
Although "$ alr with --tree" seems to give correct dependencies.
-So my "dummy question" is: do we agree that Alire manages fully dependencies & that user has not to download them manually ?
-Alire does the full job to download, install, build & what ever needed concerning the dependencies ?
Many thanks
Mark

[mosteo]

Assuming properly packaged releases, yes, alr takes care of everything related to making dependencies work. Otherwise it's a bug in the release packaging.

In my platform, alr get --build gnoga is building correctly. Likewise using it as a dependency through alr with.

What's your context? OS, etc... (alr version output).

[Hubilari]

Thanks for the answer.
I'm running Ubuntu 22.04.2 & alr version is 1.2.2
$ alr get --build gnoga
...
Build finished successfully in 19.89 seconds.

gnoga=2.1.2 successfully retrieved and built.
Dependencies were solved as follows:

+♼ gnat 12.2.1 (new,installed,gnat_native)

• libgnutls 3.7.3 (new,indirect)
• simple_components 4.62.0 (new)
• unixodbc 2.3.9 (new,indirect)
• uxstrings 0.4.0+alpha-20220803 (new)

$ (* so it seems correct *)

$ alr run
ⓘ Building gnoga/lib_gnoga.gpr...
Build finished successfully in 0.37 seconds.
error: Executable "gnoga" not found (* is it correct ? *)
dubois@db:gnoga_2.1.2_5f127c56$

-- Add dependency for gnoga
$ alr with --tree
gnoga=2.1.2
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
├── simple_components=4.62.0 (^4.62.0)
│ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ ├── libgnutls=3.7.3 (^3.5.8)
│ └── unixodbc=2.3.9 (^2.3)
└── uxstrings=0.4.0+alpha-20220803 (~0.4.0+alpha-20220803)
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
└── simple_components=4.62.0 (^4.62.0)
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
├── libgnutls=3.7.3 (^3.5.8)
└── unixodbc=2.3.9 (^2.3)
$
gnoga_2.1.2_5f127c56$ alr with gnoga (* as requested in readme.md / gnoga *)
Requested changes:

✓ gnoga ^2.1.2 (add)

Changes to dependency solution:

= gnat 12.2.1 (gnat_native)

• gnoga 2.1.2 (new)

Do you want to proceed?
[Y] Yes [N] No (default is Yes) Y

$ alr with --tree (* so we see the changes below *)
gnoga=2.1.2
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
├── gnoga=2.1.2 (^2.1.2)
│ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ ├── simple_components=4.62.0 (^4.62.0)
│ │ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ │ ├── libgnutls=3.7.3 (^3.5.8)
│ │ └── unixodbc=2.3.9 (^2.3)
│ └── uxstrings=0.4.0+alpha-20220803 (~0.4.0+alpha-20220803)
│ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ └── simple_components=4.62.0 (^4.62.0)
│ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ ├── libgnutls=3.7.3 (^3.5.8)
│ └── unixodbc=2.3.9 (^2.3)
├── simple_components=4.62.0 (^4.62.0)
│ ├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
│ ├── libgnutls=3.7.3 (^3.5.8)
│ └── unixodbc=2.3.9 (^2.3)
└── uxstrings=0.4.0+alpha-20220803 (~0.4.0+alpha-20220803)
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
└── simple_components=4.62.0 (^4.62.0)
├── gnat=12.2.1 (gnat_native) (>=2021 | (>=12 & <2000))
├── libgnutls=3.7.3 (^3.5.8)
└── unixodbc=2.3.9 (^2.3)
$

-- Compile
$ ./compile.sh

Compilation XXX

lib_gnoga.gpr:2:06: imported project file "components.gpr" not found (* although it's in the dependency & gnoga.gpr is correctly found ! *)
etc..

-==- That's all folks ! -=-

[mosteo]

error: Executable "gnoga" not found (* is it correct ? *)

This is to be expected as you're trying to run a library that doesn't create an executable.

From the rest of the log, what I see is that you're trying to add gnoga as a dependency of itself. If you want to use gnoga in your projects as a dependency, the usual workflow would be:

$ alr -n init --bin example
[...]
✓ example initialized successfully.
$ cd example
$ alr with gnoga
ⓘ Synchronizing workspace...
Nothing to update.          

Requested changes:                                                                                            

   ✓ gnoga ^2.1.2 (add)
[...]
Do you want to proceed?
[Y] Yes  [N] No  (default is Yes) 
Using default: Yes
ⓘ Deploying simple_components=4.62.0...
[...]
ⓘ Deploying gnoga=2.1.2...                                                        
[...]
                                              
$ alr run
ⓘ Building example=0.1.0-dev/example.gpr...
Setup
   [mkdir]        object directory for project Lib_UXStrings1
   [mkdir]        library directory for project Lib_UXStrings1
   [mkdir]        object directory for project Lib_Gnoga
   [mkdir]        library directory for project Lib_Gnoga
   [mkdir]        object directory for project Example
   [mkdir]        exec directory for project Example
Compile
   [Ada]          example.adb
   [Ada]          uxstrings-hash_case_insensitive.adb
   [Ada]          uxstrings-hash.adb
   [Ada]          uxstrings-text_io-text_streams.adb
   [Ada]          uxstrings-formatting.adb
   [Ada]          uxstrings-conversions.adb
   [Ada]          uxstrings1.adb
   [Ada]          uxstrings-text_io1.adb
   [C]            synchronization_linux.c
   [Ada]          gnoga-gui-plugin-message_boxes.adb
 [...]
Build finished successfully in 7.75 seconds.

As you can see, the build succeeds, and gnoga is built as part of it.

[Hubilari]

Ok, I understand the situation better.
I made a mistake while reading gnoga/readme.md. Of course, I didn't want to create gnoga as dependent on itself..
-So I now understand that "alr with gnoga" only updates the graph but does not update the dependencies itself?
-Another important question: your proposal is to create my project as a new crate, if I understood correctly.
Is it mandatory? My first request was only to use a crate, here gnoga, as another library but not to install anything intrusive on my PC.
I see a limitation on name size, alphabet, etc.
-Finally, following the example, I still have the same error.
What exactly is "example"? Is it only the root of the project or is it necessarily a binary repository? Or something else ?
Thanks
Mark

[mosteo]

So I now understand that "alr with gnoga" only updates the graph but does not update the dependencies itself?

It will update the graph, download the dependency, and configure your project (if it was created with alr init) so you're able to use gnoga immediately in your Ada code. Fire and forget, so to say.

your proposal is to create my project as a new crate, if I understood correctly. Is it mandatory?

It is if you want to work the intended, simpler way with alr. Mind you, your project being a crate only means that it starts with our template structure. It doesn't force you to publish it, or any involved process. You can then tweak your project file to suit your needs, although for regular projects there should be nothing to tweak.

not to install anything intrusive on my PC.

If you're already using alr, there's nothing more to install. You can limit your use of alr to see the environment you need for the compiler to find things with alr printenv. Although the usual way is to use alr build to do it for you, and alr edit to open your editor with the environment properly set up.

My first request was only to use a crate, here gnoga, as another library

If you wanted to use it without alr involvement, you can use alr get gnoga to get the latest version, and then configure your project to use gnoga by hand (probably leveraging the info given by alr printenv). But then, you're completely "on your own".

I see a limitation on name size, alphabet, etc.

This is necessary for the short name of the crate in the index, and so it is a valid Ada identifier for the root package of the project. After initialization with alr init, you can change whatever is needed in the sources.

Finally, following the example, I still have the same error.

This is strange as we are using the same OS and etc.

What exactly is "example"? Is it only the root of the project or is it necessarily a binary repository?

It is a fresh project I created. It would fulfill the role of your code that wants to use gnoga. It's not a repository; it's simply the default Ada project that alr init creates. The --bin/--lib switch instructs alr to use the template for a project that generates an executable or that provides a library, nothing more.

Are you familiar with the package manager of another programming language? If so I could point similarities with alr.

[Hubilari]

Hi,
-Reading carefully your Alire documentation (thanks for the job..) finally, I was able to compile, using your last proposal "alr -n init --bin example", etc.. & organizing my repositories nearly as wished.
The only & strange issue is I had to replace all the 'withed' from all *.gpr by absolute paths. Of course, no really good..
-Does Alire create paths for Ubuntu or not, please ?

-In general, would you say that Alire is similar to SNAP from Ubuntu, please?
I speak here of the philosophy / functional architecture, not really the implementation.

"Are you familiar with the package manager of another programming language? If so I could point similarities with alr."
I'm an Ada fan, since Ada 1983 & the rest doesn't really deserve the name of language, in my opinion at least. Programming shouldn't be an esoteric activity, that's why I still believe in Ada. But that is another debate that is not the subject of this post. I do a bit of C, when I have to (but then really have to..).
Thanks
Mark

[mosteo]

The only & strange issue is I had to replace all the 'withed' from all *.gpr by absolute paths. Of course, no really good..

That shouldn't be necessary, so something is likely amiss. You can inspect all the paths known to alr running alr printenv from within your workspace.

-In general, would you say that Alire is similar to SNAP from Ubuntu, please?

In the sense that each workspace contains its dependencies, yes. It's different ofc in that it deals with sources and not installed binaries, it's not creating jails...

Compilers are an exception in that are managed differently as they come packaged as binaries and not built from sources; they're downloaded to a user-wide location.

I asked about other package managers because alr shares many traits with, e.g., cargo from Rust or pip from Python. But no matter. I'm glad you were able to make it work.

[Hubilari]

Hi,
"The only & strange issue is I had to replace all the 'withed' from all *.gpr by absolute paths. Of course, no really good.."
This is OK now using "$ alr run". Issue came probably from a bad use of using directly gprbuild instead of alr run.
Thanks