I'm an experienced C++ developer, Ada newbie, trying to port a mixed C and Ada legacy codebase to GNAT Studio. I want to compile the C and Ada sources to multiple static libraries and use them from a GtkAda executable. Actually it's a pretty complicated situation as I'll detail below.

Initially I was going to ask what is the GNAT Studio equivalent of a workspace or solution file, because I wasn't finding it. But just before posting that question, I stumbled upon the documentation section for "aggregate project" in .gpr file. Yahtzee. ("Aggregate" was the one synonym I hadn't thought to google for!)

But, I still want to see this in use before I'm comfortable using it from scratch. My learning style is I learn best from examples. First I mimic, then I understand. The syntax seems simple enough, but the documentation on aggregate projects doesn't (for instance) devote any words to common conventions like whether the .gpr file is usually mixed in with the sources or at a directory level above, etc.

And the same applies to linking and calling the C code from the Ada code (or even calling the Ada lib from the exe, for that matter). As a C++ programmer (and also C#) I'm familiar with the issues (e.g. name mangling and ABI/calling conventions) with cross-language marshaling. I still want to look at a big (real) Ada project that does it.

Finally, I read that the aggregate project feature in GNAT Studio supports the same source file being included - perhaps with different interpretations - in multiple different projects. That's good news because this legacy codebase uses that model heavily to actually build EPROM (firmware) images for multiple similar-but-different circuit boards. I actually want to run all of them within the one Gtk executable (it will be a simulator or emulator, depending how you term it), so I'll have multiple different Ada libs, that used to build independent .hex or .bin files, now being combined into one executable.

Actually it's even more complicated than that. There's two legacy codebases, the second for a still-old but newer generation of the equipment, and I'm hoping to put both of those together too. (You'd select which version of the equipment you want to simulate with a radio button.) The codebases for those have different versions of the same files. If I had to I can just make that two different GtkAda programs.

Because of both combining what were multiple different EPROM images into one executable, and the possibility of combining two similar-but-different sets of EPROM images, I'm wondering if and how namespace collisions are manageable in an aggregate project. I solved a similar problem combining C++ codebases associated with these two equipment generations into one application by segregating the codebases by DLL. Since a DLL only exports the names you tell it to, it doesn't matter if the same name is used for different things internally; they can still be linked into the same program.

I work on an MFC application (C++, Windows) that communicates over serial port to an embedded system. This piece of equipment has firmware written in a combination of assembly, C, and Ada code. Although it is an x86 processor (80196 to be exact, with about 32Kb memory), it's custom hardware and not PC based. Also the underlying OS is a unique RTOS developed by the equipment vendor, not based on any other OS or RTOS.

I'd like to run the actual firmware in a Windows program, either in an emulator or port the code to run as a Windows program so I can debug it and see where data goes as my MFC application communicates with it. Emulating the system so it runs the binary firmware is one possible avenue, but I'm writing this post to ask about the second - porting the source code so I can make a Windows program out of it.

I am experienced porting C to other operating systems, and the assembly language and RTOS functions I believe I could implement or stub out myself. (This would considerably easier than the original development of the RTOS, as I could use a higher level language and as much resources as I want.)

What I'm less strong on is the Ada code. I'm more of a C++ developer. So I'm not sure the best approach here. Is Ada more like Java (write once run anywhere) so that Ada code written in the late 80s through the 90s can also be compiled on a modern Ada compiler for different OS? Or is it like VB6 to VB.NET transition where the old style of the language is hopelessly out of date? Or kind of in-between like C where there's a lot of backward compatible support, but porting it I might have to fix places where it makes assumptions about the word size of the hardware, etc.?

What tools or compilers would you use if you were me? I'm evaluating a long-abandoned open source Ada to C++ translator (if I just transpired all the Ada code to C++ once and compiled that, it would meet my needs), but I don't know whether it was fully functioning or barely implemented before the project was abandoned.

I also thought about writing an Ada interpreter as then I could handle details of emulating virtual hardware within the interpreter. (Lest that sound crazily ambitious, or a non sequitur since Ada is typically compiled, allow me to point out writing a compiler or an interpreter that only needs to work for ONE given program is a significantly less general task than writing a full one. And C interpreters exist.)

As I write this, I'm realizing building a mixed Ada and C++ program is probably the less masochistic way to approach this (if only because finishing an abandoned translator or writing an interpreter are even more so). I think I was mostly scared of finding gcc not supporting this dialect or vintage of Ada (they used an old version of the DDCi compiler), or difficulty stubbing out the hardware support.