Re: C++/cmake project, injecting Ada...

["Alex R. Mosteo" <alejandro@mosteo.invalid>]

Ludovic Brenta wrote:

> "Alex R. Mosteo" <alejandro@mosteo.invalid> writes:
>> As I was writing this reply, I realized that focusing in a particular
>> case at hand may provide better food for though and more precise
>> solutions. So I have renamed the thread accordingly. Now, the scenario
>> is like this:
>>
>> A fairly conventional open source project for doing some high-level
>> simulations. C++ based, using cmake for building. Developers using an
>> assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3
>> versions). Eventually, MacOSX could enter the fray. Remember, this is
>> loosely cooperative research, nobody mandates the devel platform to a
>> particularly tight version.
>>
>> The project uses several libraries: boost, YARP, opencv, etc, which
>> are located by cmake. Somehow all this compiles in such varied
>> environments.
>>
>> Now, let's suppose the contributions are fairly self-contained (e.g.,
>> providing a particular class instance for an abstract base class). I
>> know how to interface Ada and C/C++, don't mind to write glue code as
>> needed, etc.
>>
>> The challenge: throwing Ada into this mix without disrupting
>> everyone's workflow to an unreasonable level. The obstacles that I
>> see, and for which your ideas are most welcome:
> 
> My first reaction is: don't do it.  The chances of failure are very
> high, if only because of the diversity of platforms and the absence of a
> "stock" Ada compiler on each.  The integration between Ada and cmake is
> another potential hurdle.  Any failure will be promptly blamed on "your
> non-standard language and tools" even though cmake is just as
> "non-standard" as gprbuild; you'll end up being the only person in
> charge of debugging everyone else's build problems.

I see my fears are then reasonable, because that's how I feel too. It's not 
bad enough that few people know/use Ada, one is further excluded by things 
like this.

> It should be possible, however, to create separate add-ons in Ada.
> Compile these add-ons independently from the main project, using
> gnatmake or gprmake; do not require any developer not interested in your
> add-ons to change anything to their toolchain.  The interfacing between
> the add-ons and the main project is the crux of the matter; if you could
> do it via some sort of interprocess communications, you would be able to
> isolate your add-ons from the main project very well.  Otherwise,
> provide a shared library that the main project can dlopen() and call
> (use pragma Export to expose the API to the shared library).

This is an interesting possibility, and in fact IPC in this particular lab 
is many times done via YARP (tell about killing flies with cannons), 
meaning, if you don't know it, that processes are totally independent, 
communicating over sockets. So this is a possibility to keep in mind. Also 
the dlopen possibility is interesting, although a bit less attractive 
because dlopen shenaningans are not used right now (I suspect). Still worth 
to keep in mind, thanks. 

> A last resort perhaps: fork the open source project; do anything you
> like in Ada, replace cmake with gprbuild or whatever.  Merge from the
> open source project from time to time.  Care only about your platform;
> if anyone is interested in building on another, provide assistance as
> needed.  Publish your sources in a separate branch in their version
> control system if you can (and if the VCS supports merges well, i.e. it
> is not CVS or subversion...) or in a monotone database if you must.

Last resort indeed :) Although interesting from the POV of seeing how 
gprbuild would deal with a large complex cmake project. Perhaps worth it 
(once) only for that part of the experience.

Thank for your opinions, much valued because I know you're deeply 
experienced into the Debian/open source community. I see that basically my 
understanding of the situation was on target :(

Going again over it, I still think that perhaps exploring the cmake+Ada way 
is the more promising in terms of achieving something with relative ease? I 
see two venues here:

1) Just drop all advantages of gprbuild dependency management, and compile 
each Ada file to object code. Problems I see: what happens with gnatbind?

2) Somehow massage cmake into using a single call to gprbuild, and normally 
use it to compile the Ada part into a library. I guess this library can be 
easily linked with the rest of C/C++ compiled sources, since I have seen 
cmake projects which build many intermediate libraries. Since there's only 
one interaction between cmake and Ada (launching gprbuild), perhaps the 
problem of debugging everyone's else builds would be a reasonable burden; 
especially if the Ada parts are disabled by default and only compiled by 
people interested in them.

Alex.