From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1c8c283347cf0236 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: C++/cmake project, injecting Ada... Date: Thu, 28 Apr 2011 18:34:08 +0200 Organization: A noiseless patient Spider Message-ID: <87liyugwsf.fsf@ludovic-brenta.org> References: <8ee03ab1-6745-4aa4-82ee-be1eccc9afc9@p3g2000vbv.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx01.eternal-september.org; posting-host="+bbuZPFF95m3zaJmUE1KYg"; logging-data="2933"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uP8cC9CeWr3xjmiAGQPgn" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:09kELYg+IDZbUee7Awfn1Izgmlo= sha1:tHykWSSxjcPleABrkZR1DSAThTg= Xref: g2news1.google.com comp.lang.ada:19075 Date: 2011-04-28T18:34:08+02:00 List-Id: "Alex R. Mosteo" 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. 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). 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. -- Ludovic Brenta.