Duplicate project name "gnatcoll" error.

[Blady-Com]

Hello,

I aim to build GPS from Github latest source codes (commit 2891973).
Unfortunately, I've got a tricky issue with new Gnatcoll-core (commit 23330f798d3f16437c9192b6ff255faa8caf8d2c):
gnatcoll.gpr:10:17: duplicate project name "gnatcoll"
gnatcoll.gpr:10:17: already in "/gnatcoll-core/build/share/gpr/gnatcoll.gpr"

See attached full log.
20171203-GPS-build-error.txt

However, former Gnatcoll source code didn't make this error.
Configuration: macOS, GNAT GPL 2017, GTKAda, GnatColl and other components from GITHub/AdaCore.

Is it coming from new Gnatcoll-core build or something else?

Thanks for your help, Pascal.

[godunko]

GPS is not moved to new structure of GNATCOLL yet. It is work in progress, please wait till it will be completed.

[steve-cs]

FYI. With recent changes GPS now builds on new gnatcoll. It still has some unmet run time dependencies, e.g. libadalang.py _ctypes.py, ???, which may just be my environment that I haven't tracked down yet. My workaround was to remove LAL and libadalang from gps until that stabilizes or I fix my issues, accomplished with a small set of patches to gps.gpr, gsp-main.adb, and python_module.adb. With that and a set of symbolic links to map gnatcoll-* to gnatcoll_* in /share/gpr I seem to have gps building and running.

My current gps patch: master...steve-cs:master

Makefile (evolving work in progress) for bootstrapping: https://github.com/steve-cs/gnat-builder

Summary: One doesn't necessarily have to wait much longer if they don't want to. IMO of course.

[Blady-Com]

Thanks Steve for sharing.
I've almost got the same point but my gps stops with:
ImportError: No module named site
Which launch script do you use?
Thanks for your help, Pascal.

[steve-cs]

For now, I just do a "make gps-run" from the Makefile I referenced above. It just points at a few of the python 2.7 directories for the missing modules, e.g. site.py. I'm not sure that all three directories are needed for running the "master" gps. They were for me when I bootstrapped the gpl-2017 sources on top of a FSF GCC-7.x (patched gnat_utils needed). With LAL / libadalang removed from the gps build, there wasn't any need for any LD_LIBRARY_PATH hackery. If memory serves that avoids having to fix loading of libadalang.so and a python import of module _ctypes.py, maybe more. At least that was my experience building on Debian stable. The relevant launch script is at the bottom of the Makefile.

.PHONY: gps-run
gps-run:
export PYTHONPATH=/usr/lib/python2.7:/usr/lib/python2.7/plat-x86_64-linux-gnu:/usr/lib/python2.7/dist-packages
&& gps

gps starts and will create and build a sample project. It does complain about gnatinspect after a build. That's because gnatinspect hasn't been added to the modular gnatcoll-db build properly yet. The source looks to be there but gnatinspect.gpr is missing. I think that should be relatively simple to fix, but I haven't done it yet. Other things might be missing or broken at run time of course.

With any luck that may get yours to work. If not, I've added a release in my github account which contains a snapshot of the /usr/local/gnat directory from my build machine which might provide more clues to compare the result of my build against yours.

https://github.com/steve-cs/gnat-builder/releases/tag/v0.1.0-20180105

-Steve

[setton]

Great going @steve-cs! it would be nice to have a gnatinspect build indeed, I think the gnatcoll team will sort this out soon... in the meantime you could always put in your PATH the gnatinspect executable from the GNAT community edition, to get navigation working again.

And really hoping we'll get a package manager at some point, which will handle the builds of gtkada, gnatcoll, libadalang, etc.

[steve-cs]

it would be nice to have a gnatinspect build indeed

Adding a gnatinspect.gpr was all that it took to get it to build and install. But unsurprisingly it doesn't run correctly yet. As you seem to imply probably best/easiest to wait for the gnatcoll team for an update and move on to something else. Or maybe it will bother me and I'll dig a little deeper.

https://github.com/steve-cs/gnat-builder/releases/tag/v0.1.0-20180107

[steve-cs]

@setton: digging one step deeper...

I'm not sure why I was still blaming the gnatinspect build. At this point I don't know if it is working or not. The error messages that appear in gps console on startup indicate something else. Perhaps because I cut out the LAL initialization? If not, it's not clear to me whether the root cause is in gps, the gps/gnatcoll integration, or the gps/libadalang integration, or somewhere else. In case the error messages are helpful, I've copied them below:

warning: could not load module clang_support.Clang_Module
Traceback (most recent call last):

File "/usr/local/gnat/share/gps/support/core/modules.py", line 309, in _setup
self.setup()

File "/usr/local/gnat/share/gps/support/languages/clang_support.py", line 110, in setup
Clang_Module.show_diags_pref_val = show_diags_pref.get()

AttributeError: 'NoneType' object has no attribute 'get'

Traceback (most recent call last):
File "/usr/local/gnat/share/gps/support/core/modules.py", line 255, in internal
return pref(*args, **kwargs)
File "/usr/local/gnat/share/gps/support/languages/clang_support.py", line 115, in semantic_tree_updated
if self.is_on():
File "/usr/local/gnat/share/gps/support/languages/clang_support.py", line 101, in is_on
return show_diags_pref.get() != DISABLED
AttributeError: 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
File "/usr/local/gnat/share/gps/support/core/modules.py", line 255, in internal
return pref(*args, **kwargs)
File "/usr/local/gnat/share/gps/support/languages/clang_support.py", line 115, in semantic_tree_updated
if self.is_on():
File "/usr/local/gnat/share/gps/support/languages/clang_support.py", line 101, in is_on
return show_diags_pref.get() != DISABLED
AttributeError: 'NoneType' object has no attribute 'get'

[...]

[setton]

I guess you deactivated a bit too much code, or not enough :-)

GPS uses libclang for navigation and code completion in C/C++ - you can either add this and reactivate clang_module in the Ada code, or remove clang_support.py and let go of
C/C++ capabilities.

[steve-cs]

Thanks for the clue. Looking deeper into the gps run time log there are multiple things going on. The primary suspect for the Clang_Module not loading looks to be a Python environment problem: 'No module named_cytpes'. In any case, I should have caught and fixed that earlier.

It still feels close. I'll work through this.

[Blady-Com]

Very first successful build on macOS ;-)
Thanks Steve for the tip on Python path, on my side I use GPS_PYTHONHOME, see below.
I've committed all my modifications on:
Branch: https://github.com/Blady-Com/gps/commits/macos
Commit: Blady-Com@04ec995
Instructions on macOS (with GTK from XNAdaLib (https://sourceforge.net/projects/gnuada/files/GNAT_GPL%20Mac%20OS%20X/2017-el-capitan/):
$ export GPR_PROJECT_PATH=/Users/moi/Documents/Programmation/SVNGIT/GTKAda/build/lib/gnat:/Users/moi/Documents/Programmation/SVNGIT/libadalang/build/lib/gnat:/Users/moi/Documents/Programmation/SVNGIT/libadalang-tools/src:/Users/moi/Documents/Programmation/SVNGIT/gnatcoll-core/build/share/gpr
$ PATH=/usr/local/xnadalib-2017/bin:$PATH
$ ./configure --with-clang=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib
$ make LIBRARY_TYPE=static
$ ln -s share share/gps
$ install_name_tool -add_rpath /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib gps/obj/gps
$ XDG_DATA_DIRS=/usr/local/xnadalib-2017/share GPS_ROOT=$PWD GPS_PYTHONHOME=/usr/local/gnat-2017 GPS_HOME=gps/obj gps/obj/gps
Most of basic menu items are working e.g. editing and compiling.
Some non blocking errors remains:
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/gnat-2017/lib/python2.7/site-packages/gi/init.py", line 100, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available
I've attached log file if it may help:
log.81406.txt
Best, Pascal.

[steve-cs]

(editted: 2018/01/20)

Summarizing, my short list of issues that currently prevent gps from building on top of gnatcoll and libadalang as is:

1. libadalang doesn't build because of a dependency in langkit on gnatcoll_iconv.gpr which no longer exists.
2. gps doesn't build because of multiple dependencies on gnatcoll-*.gpr which which no longer exist.
3. gps doesn't build because of a recent change in libadalang regarding GET_UNIT_FILENAME.
4. gps doesn't build because of compiler complaint about Is_Null ambiguity in libadalang-tools

The following one line patch to langkit appears to resolve the first issue:
https://github.com/steve-cs/gnat-builder/blob/master/patches/langkit-src-patch-1

The following patch to multiple files in gps appears to resolve the second issue:
https://github.com/steve-cs/gnat-builder/blob/master/patches/gps-src-patch-2

gps was building on libadalang, but apparently broke because of the following recent commit. I don't have a proper patch for that, but instead work around by removing lal and libadalang from the gps build with the following patch.
AdaCore/libadalang@a16e6e1
https://github.com/steve-cs/gnat-builder/blob/master/patches/gps-src-patch-1

The GET_UNIT_FILENAME issue has been resolved, but reenabling lal and libadalang reveals a remaining issue in libadalang-tools which I'll detail in a following comment.

Would it be at all helpful to create separate issues or pull requests, or is the best approach to assume these type of things are already on Adacore's list and will appear in the near future?

[setton]

Thank you for the summary! AdaCore’s intent is definitely to sort this out soon.

[steve-cs]

Confirming that items 1 and 2 from my previous short list have been resolved and my corresponding patches obsoleted by recent commits to gnatcoll-bindings and gnatcoll-db.

[steve-cs]

Confirming that item 3 from my previous short list has been resolved by recent commits.

I've added a new item 4. gps doesn't build because of compiler complaint about Is_Null ambiguity in libadalang-tools

Building gps with ./laltools pointing libadalang-tools source fails with the following complaint:

pp-formatting.adb:63:62: ambiguous expression (cannot resolve "Is_Null")
pp-formatting.adb:63:62: possible interpretation at line 63
pp-formatting.adb:63:62: possible interpretation at libadalang-analysis.ads:1147

compilation of pp-formatting.adb failed

The offending line in question is:

function Is_Null (Tree : Ada_Node) return Boolean is (Tree.Is_Null);

Renaming the function to Is_Null_Local seems to resolve this and allows gps build to complete. The following patches 3 lines to accomplish that:

https://github.com/steve-cs/gnat-builder/blob/master/patches/libadalang-tools-src-patch-1

I don't know if this should be necessary or if this could be a compiler issue as I'm using a gcc-7-branch compiler, specifically gcc version 7.2.1 20180118. Please advise.

[setton]

Hm, you might need to switch to the "stable-gps" branch of libadalang, langkit, and libadalang-tools.

[steve-cs]

Confirming that stable-gps libadalang/langkit builds on master gnatcoll-* and master gps builds on stable-gps libadalang/langkit with stable-gps libadalang-tools source.

For some unknown reason I was assuming that stable-gps was a snap shot. But it looks like it is still under active maintenance. I'll consider it. Thanks.

[steve-cs]

Unless I'm mistaken the ambiguous Is_Null issue is now present when building with stable-gps branch of libadalang, langkit, and libadalang-tools as well. It also seems to resolve and build with the same patch as above. At the moment stable-gps branch seems no better of a work around so I've reverted to building all repositories on their respective master branches. FYI my build status is updated every 24 hours at:

https://github.com/steve-cs/gnat-builder

[steve-cs]

Recent commits to gps anticipating changes to Gtkada have broken the build as Gtkada repository on github doesn't have those changes yet.

[setton]

gtkada should have the changes now.

[steve-cs]

Confirmed, updates to gtkada repo resolved that specific issue. Thank you.

However gps build on my system is still broken due to another recent commit: a6c7a2e

./gps-build/gvd/src/debugger-base_gdb-gdb_cli.adb

gprbuild  -m -p -ws \
  -XBuild=Debug -XOS=unix -XLIBRARY_TYPE=relocatable -XXMLADA_BUILD=relocatable -Pgps -largs `pkg-config gmodule-2.0 --libs`
Compile
   [Ada]          debugger-base_gdb-gdb_cli.adb
debugger-base_gdb-gdb_cli.adb:4163:25: "Terminate_Process" not declared in "TTY"

   compilation of debugger-base_gdb-gdb_cli.adb failed

The offending line is:

GNAT.Expect.TTY.Terminate_Process (Debugger.Debuggee_Pid);

Reverting that commit allows gps (master) to build on my system (Linux/Ubuntu/Artful with latest gcc-7-branch compiler). I'm assuming the clue is in g-exptty.ads.

[steve-cs]

I should have checked earlier. GPS builds with GCC trunk (8.0.1) but does not with GCC gcc-7-branch (7.3.1). It's a library issue in FSF GCC as compared to AdaCore.

Procedure Terminate_Process (PID : Integer) was added to GCC Trunk on or about 2017-04-25 as reflected in the following commit: gcc-mirror/gcc@e97dbe8

It also exists in AdaCore GNAT GPL-2017, but never made it into gcc-7-branch. It looks straight forward to back port. I'm assuming this is my problem, unless someone at Adacore wants to contribute the back port to GCC.

[steve-cs]

It turns out that the back port of "Procedure Terminate_Process (PID : Integer)" within gcc itself is indeed trivial. Copying g-exptty.ads, g-exptty.adb, and terminal.c from gcc trunk to gcc-7-branch looks to be a clean/safe patch which only adds this one procedure (and corresponding C code). So that's what I'm using now.