Change realpath command to Python realpath function.

[Blady-Com]

Rational: realpath command isn't available natively in all environments (especially macOS) but Python should be as it is required for GPR2 build.

[simonjwright]

For info, realpath is available in macOS SDKs v15. But older machines can’t install SDKs v15.

[lukaselmer]

realpath may also work differently on macOS?

[...]

    [Ada]          gpr2-file_readers.adb
     [Ada]          gpr2-source_reference-identifier-set.ads
     [Ada]          gpr2-project-parser-create.adb
     [Ada]          gpr2-source_info-parser-registry.adb
  Build Libraries
     [gprlib]       gpr2.lexch
     [archive]      libgpr2.a
     [index]        libgpr2.a

  realpath: illegal option -- -
  usage: realpath [-q] [path ...]
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /gpr-rust/examples/ada_hello/target/debug/build/gpr-61520f600424e2cd/out/contrib/gpr/.build/release/lib-static-pic/libgpr2.a(gpr_parser-gdb.o) has no symbols
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /gpr-rust/examples/ada_hello/target/debug/build/gpr-61520f600424e2cd/out/contrib/gpr/.build/release/lib-static-pic/libgpr2.a(gpr_parser-gdb.o) has no symbols
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /gpr-rust/examples/ada_hello/target/debug/build/gpr-61520f600424e2cd/out/contrib/gpr/.build/release/lib-static-pic/libgpr2.a(gpr_parser-gdb.o) has no symbols
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: /gpr-rust/examples/ada_hello/target/debug/build/gpr-61520f600424e2cd/out/contrib/gpr/.build/release/lib-static-pic/libgpr2.a(gpr_parser-gdb.o) has no symbols

  Setup

[...]

[Jicquel]

Hello, and thank you for your contribution. First, we apologize for the delay.

You are right; realpath seems to be an issue for macOS. However, Python is not required to build gpr2/libgpr2, but only to regenerate the GPR parser from the Langkit grammar. Using Python for realpath would add a new dependency during the build process.

Or, we could just remove the out-of-tree Makefile softlink support: realpath is there to detect the case where the dev has an out-of-tree build directory in which he soft-linked the Makefile for ease of use (so typing make there just works). As this causes issues and fixing it with Python adds new dependency, I think we can simply remove this functionality.

@Blady-Com, do you want to update the PR yourself, or let us do it ? I will give you some time so you can decide the best option.

[Jicquel]

As a workaround for macOS users,

make MFILE=./Makefile)

should fix the issue

[lambourg]

Hello there, so as mentioned by @Jicquel, python is currently not needed to build libgpr2 or the gpr2 tools. We currently use python for two specific stages: re-generation of the gpr parser - whose sources are otherwise statically stored in the repo -, and testing. So the proposed change is currently disruptive for our build system that don't have a controlled python install at hand during build, so cannot be accepted right now unfortunately.

For the record, this call to realpath is there to handle the case where some developer has a dedicated build directory and symlinked the Makefile in there to just have to type make and have the result there. Particularly useful when you have several makefile.conf to test (those remain local to your build tree).

If you fix the MFILE variable to the expected value given by realpath, then the tool should not be called so the build should be fine on MacOS.

This being said, python is widely used otherwise for building things at AdaCore, and considering the complexity of maintaining Makefiles compared to maintaining python-based build systems, we intend to move to python at some point: this should make portability of the build much easier...

[simonjwright]

considering the complexity of maintaining Makefiles compared to maintaining python-based build systems, we intend to move to python at some point

I have a feeling that you may not be joking .. your python-based build systems may be fine for you, with colleagues who can explain the undocumented mysteries, but for the rest of us .. not so much.

[Blady-Com]

considering the complexity of maintaining Makefiles compared to maintaining python-based build systems, we intend to move to python at some point

I have a feeling that you may not be joking .. your python-based build systems may be fine for you, with colleagues who can explain the undocumented mysteries, but for the rest of us .. not so much.

I fully agree with @simonjwright. Python scripts used in other AdaCore components aren't enough documented in order to investigate when something goes wrong. Makefile are more straightly readable (though ... :-)

@Jicquel, your proposed workaround is fine for me. Take care you need to change assignment mode of MFILE: MFILE = $(shell realpath --relative-to=. "$(firstword ${MAKEFILE_LIST})")) and add quotes when calling make: % make MFILE="./Makefile)"

Don't forget also the additional fix for SOURCE_DIR.

[Nikokrock]

considering the complexity of maintaining Makefiles compared to maintaining python-based build systems, we intend to move to python at some point

I have a feeling that you may not be joking .. your python-based build systems may be fine for you, with colleagues who can explain the undocumented mysteries, but for the rest of us .. not so much.

Do you have a particular AdaCore project in mind ? Some like gnatcoll-bindings are using very simple scripts that should be easy to understand. The main advantage of not using Makefiles is that this is more friendly on pure Windows development environment.

[simonjwright]

So sorry to have left this so long.

The ones that I find really challenging are the GNAT-FSF-Builds ones.

[Nikokrock]

The compiler build is really a separate matter I think :-). We rely indeed on some internal technology that has been partially put public to make the whole process transparent (was not the case in the past). We plan to make that technology more public in the future but we don't have a clear roadmap yet.