For the possibility of building florist with drake

[Earnestly]

Before starting I do think this may end up as a "WONTFIX" because http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-7.html does not define Interrupt_Management, however if there is a potential for a system.interrupt_management implementation it might be the step needed to get florist built against drake.

Using florist-gpl-2017-src.tar.gz I am able to modify Makefile.in to include the necessary --RTS option like so:

- GPRBUILD_FLAGS = $(GCCFLAGS) $(LIBRARY_TYPE_OPTION) $(PROJECT_FLAGS)
+ GPRBUILD_FLAGS = $(GCCFLAGS) $(LIBRARY_TYPE_OPTION) $(PROJECT_FLAGS) --RTS=/usr/lib/drake/x86_64-pc-linux-gnu/7.2.0

After the usual ./configure I get the following errors from make (gprbuild):

gprbuild -p -O2  -XTHREADS=True   --RTS=/usr/lib/drake/x86_64-pc-linux-gnu/7.2.0 -Pflorist -cargs -O1 
Setup
   [mkdir]        object directory for project Florist
   [mkdir]        library directory for project Florist
Compile
   [Ada]          posix-timers-extensions.adb
posix-timers-extensions.ads:37:21: "SYSTEM.INTERRUPT_MANAGEMENT" is not a predefined library unit
posix-timers-extensions.ads:37:21: "POSIX.TIMERS.EXTENSIONS (body)" depends on "POSIX.TIMERS.EXTENSIONS (spec)"
posix-timers-extensions.ads:37:21: "POSIX.TIMERS.EXTENSIONS (spec)" depends on "POSIX.TIMERS (spec)"
posix-timers-extensions.ads:37:21: "POSIX.TIMERS (spec)" depends on "POSIX.SIGNALS (spec)"
posix-timers-extensions.ads:37:21: "POSIX.SIGNALS (spec)" depends on "SYSTEM.INTERRUPT_MANAGEMENT (spec)"
gprbuild: *** compilation phase failed

[ytomino]

Florist is just an implementation of POSIX.5(Ada interface to the POSIX system calls), specialized to GNAT.

Based on that, on GNAT, System.Interrupt_Management is not declared in System, but a child package, s-intman.ads. It's not marked as a library, belongs to details of implementation. Generally it should not be used from others. Also, s-intman.ads is not last one. Even supposing it's emulated in drake, in next, you will see GNAT.Task_Lock and Interfaces.C_Streams are missing.

If we grapple squarely with this issue, making new version of POSIX.5 for drake is legitimate way. However, the translate headers C.* have already been existing, so I don't feel it is necessary. The functions of those are same.

OK, Indeed, the most part of existing Ada libraries not only florist are specialized to GNAT. A compatibility layer is necessary in practical use. I had thought so too a few years ago and tried to make it, started from https://gist.github.com/ytomino/4649592 that is the minimum for AUnit. Then, I gave up after 10 days.

Even either "POSIX.5 for drake" or "(full set of) compatibility layer", those are large works and beyond my capacity...

When focusing only on a minimum compatibility layer only for florist, it may be satisfied with making 3 or 4 packages, perhaps.

[Earnestly]

Thank you for clarifying the situation. I suppose it does make sense that florist is an implementation based on GNAT's runtime. The amount of work is even more significant than I expected.

I'm not pressing for this to be added so feel free to ignore this issue since it is a tad out of scope.

If I ever properly learn Ada and these details I may try help implementing more of these things.

[ytomino]

I have created the repository of the previous and halfway minimum compatibility layer.

Roughly I have succeeded to build Florist with drake in Mac OS X. However, there are many unimplemented. (I faked with raise Program_Error) I don't have tried to execute any tests or applications using it, but don't think it's able to withstand practical use.

If you try, here is an experimental procedure:

cd drake
patch -p0 ../gnat4drake/florist.diff
make ... RTSDIR=... # install
cd ../gnat4drake
./configure --RTS=... # generating gnat.gpr and c.gpr
cd ../florist
./configure ...
vi Makefile # same as your change
vi florist.gpr # insert 'with "gnat";' to the first line
export GPR_PROJECT_PATH=$PWD/../gnat4drake
make

I had unexpected that the change to the packages also required by compiler is needed. Honestly, I don't want to apply this change into this repository. Probably this patch will be left.