Build failure using bootstrap.sh

[Earnestly]

• gcc 6.2.1
• GNAT 6.2.1 20160830
• Linux 4.7.5

Cloned both gprbuild and xmlada:

cd gprbuild
./bootstrap.sh --prefix="$srcdir"/bootstrap --with-xmlada="$srcdir"/xmlada

gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/src/gprbuild-main.adb
gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr.adb
gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr-conf.adb
gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr-debug.adb
gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr-env.adb
gcc -c -I./ -I./src -I./gpr/src -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/sax -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/dom -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/schema -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/unicode -I/home/earnest/build/store/gprbuild-bootstrap-git/src/xmlada/input_sources -O -I- /home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr-err.adb
gpr-conf.adb:1012:28: "Is_Owner_Writable_File" is undefined
gnatmake: "/home/earnest/build/store/gprbuild-bootstrap-git/src/gprbuild/gpr/src/gpr-conf.adb" compilation error

[gingold-adacore]

You need a more recent version of gnat!

[pmderodat]

FYI, the patch that adds Os_Lib.Is_Owner_Writable_File isn’t yet comitted at the FSF. So building the gprbuild’s master branch will not be possible until then.

[Earnestly]

I see, the solution is patience then. Thanks

[DLightstone]

Until then, which git tag is consistent with the various GPL versions available at
http://libre.adacore.com/download/

Probably a good idea to post those tag identifiers in the build instructions

[t-14]

@DLightstone thanks for the suggestion. We need to review on this side how we support publicly available versions.

[t-14]

By means of a workaround, replacing "Is_Owner_Writable_File" with "Is_Writable_File" should work. In fact we will probably install this change until at least GPL2017 is out.

[DLightstone]

This is a global phenomena. A need for tag identifiers is also present in Couverture. ( Olivier Hainque is aware of the observation).

[t-14]

I don't think tags or branches is a viable solution. If there is a separate branch for the public it will certainly stagnate and bit-rot since we don't have resources to keep it in sync. We will just try to do more to ensure the head is backwards compatible with a reasonable selection of public toolchains (and for sure at least with the fsf head!).

[DLightstone]

The general public does not get to work from the tool chain (compiler, gtkada, etc) development CM tip, you do. The GPL versions released to the public are defacto branches (they simply are not called branches)

I would not suggest attempting the maintain a branch. Simply identify the tag consistent with the tool chain available to the general public. Without the tag (for software source released via GITHUB) the public will simply have to search for the consistent versions (as I did). This either by trial and error build, or via web search.

Attempting to maintain backward compatibility just doesn't seem to be a good idea. (haven't thought about it much). My initial impression is -
As the release date of tool chain dependencies approaches the effort to maintain backward compatibility becomes inappropriate. Once the new version of the dependent tool becomes available the backward compatibility becomes a constrain upon the future. Eventually it will have to be removed (I believe this is commonly called Technical Debt)

[t-14]

You won't need tags if the project is compatible with the last GPL release, which is like I said the goal we want to aim for.

[DLightstone]

Maintaining project compatibility is a noble goal. When it cannot be achieved, or when compatibility is temporarily violated the tag is the reference point. It is nothing more than that.

[t-14]

Sure :) Here however I think it's achievable (the patch is currently on review). The disruptive change is 17143e7 but it's a few months old so I really prefer to not lock the users to such an old version.

[t-14]

Should be fixed by 926cbd5.

[Earnestly]

Perhaps you missed one?

gpr-util.adb:2030:15: "Is_Owner_Writable_File" is undefined

[t-14]

Argh. Sorry about that. Patch is on review. We are working on setting up a build with GPL2016 on our side to catch this.

[DLightstone]

Are you building GNAT GPL2016 from source, or just installing from the binary distribution?

[t-14]

It's "software present tense" ATM, but we'll no doubt use the official binary to make sure we are testing exactly what others would download.

[DLightstone]

I would hope that the official binary release is installed on a clean machine when the testing is performed. This for purposes of avoiding pollution attributable to previously installed software.

[t-14]

I am sure we'll figure it out ;)

[DLightstone]

I have no doubt that you will figure it out.

The only reason I mentioned it relates to an observed difficulty building the binaries from source. Some makefile rules appear to be missing. Clearly the binaries were built, so that implies the distribution source was either prepared on the wrong computer, or the distribution was never tested. or my build environment is not consistent to the reference AdaCore build environment.

[Earnestly]

I just hope they don't "figure it out" like they figured out traversing PATH to find something resembling a C compiler instead of using cc, or how they hardcode installation directories because it's "invarient" while still offering ./configure options to set them.

[DLightstone]

Earnestly,
I suspect the reference to "figure it out" was to a question of testing logistics, rather than product development

[t-14]

I just hope they don't "figure it out" like they figured out traversing PATH to find something resembling a C compiler

@Earnestly while I am pleased that you haven't given up after all, I don't think this kind of tone is very constructive. It is also a bit hurtful given that we've reviewed the build procedure based on your feedback.

while still offering ./configure options to set them

Not sure what you are referring to, given there is no configure at all anymore.

[t-14]

@DLightstone,

The only reason I mentioned it relates to an observed difficulty building the binaries from source. Some makefile rules appear to be missing.

Are you referring to GNAT GPL2016 or to GPRbuild?

[DLightstone]

The reference is to GNAT GPL2016

[t-14]

Understood. You should report it using the standard channel then. Let's keep this discussion limited to GPRbuild.

[DLightstone]

Earlier I indicated that there may be missing rule in the GANT GPL 2016 source. This is incorrect.

Somehow I corrupted the source which I was using for my build.
A build on clean machine was succesful