GPS in source dependances.

[Blady-Com]

Hello, GPS building embedded some dependences in its source folder as ada language server, vss, etc. Thus it prevents to have different branch selection from their respective repo. Couldn't these dependences build and install as others? I can propose a pull request in that way. Tell me if it is ok for you. Regards, Pascal.

[steve-cs]

There has been a significant amount of brokenness in the past. I haven't checked lately, but my guess is that some but not all can be built and installed separately. Issues have included: 1) no install target in the module's Makefile, 2) module builds but fails to install properly, 3) module still needed in tree for the gps build or install regardless.

If for example you want to test a separate branch for ada_language-server, a possible workaround would be something like:

make adacore-version=branch1 ada_language_server-src
make adacore-version=branch2 gps

There are significant differences in the wavefront/master, 21.x, and 20.x builds. Which are you proposing to change?

Could you describe the specific problem you're trying to work around?

[Blady-Com]

I'm building GPS gtk-3.24 branch which does't exist in these dependencies repo ;-) I haven't check their installation process but I see an install target in Ada Language Server makefile for instance. So I was wondering why not installing them before GPS building. Your workaround is valuable. It's a matter a taste ;-) I may give a look on their install process if it could be included later.

[steve-cs]

OK. gtk-3.24 branch is a good excuse. Alternatively what we want is to build different versions of gtkada and have gps branch track gtkada branch. Basically adding "gtkada-version ?= master" as a config option and using it instead of adacore-version for pulling gtkada-src and gps-src. I haven't tried it yet, but that seems simpler and cleaner to me in the short term. How does that work for you?

Edit: The above is too simple. gps branch names are sometimes subtly different than gtkada branch names, e.g. 21.2-gtk-3.22 vs 21.2-gtk-3.22.30. Sigh. One step less simple would be to add config variables for both gtkada-version and gps-version. More thinking needed.

So I was wondering why not installing them before GPS building.

The main reason is that Adacore internally is still building gps with (at least) these modules in the gps build tree. I resisted submitting the issues to Adacore while they still have some more important issues that should land ahead of that, e.g. removal of python2 dependencies.

I may give a look on their install process if it could be included later.

It's on my list of things to do. If memory serves the last time I tried VSS doesn't have an install and there were issues with removing libadalang-tools and spawn from the gps build. And so I gave up and reverted to something that worked.

[steve-cs]

Hello @Blady-Com,

Please take a look at my latest commit https://github.com/steve-cs/gnat-builder/commit/86d01e933fdb07d8888fabb490a9dc9c0da7770b to see an example where I am successfully building gtkada and gps from branch gtk-3.24 using a recent GCC (11.0.1 20210315) based toolchain. It just adds gtkada-version and gps-version variables that allow independent branch selection for gtkada and gps source repositories. This does replace/break my previous suggested workaround.

Please note that I'm currently pinning libadalang-tools ada_language_server vss spawn and gps sources at March 11 due to code that was introduced in ada_language_server which currently trips a bug/crash in 11.0.1 GCC as described in Issue https://github.com/steve-cs/gnat-builder/issues/36.

This may help you build with gtk-3.24 if you haven't already got it working.

[Blady-Com]

Many Thanks Steve, GPS is building without source code change. It's a great achievement :-) I just modify two lines:

• add old GPR_PROJECT_PATH when new one is initialized (for GTKAda, GNATColl, etc)
• suppress gps-build-patch as it can be set in gps options, here is my commande line: make sudo= os=darwin gps prefix=$instxada gps-options=--with-clang=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib

I will propose these changes in a pull request. Unfortunately, there are errors when linking:

   [link library] libspawn_glib.dylib
Undefined symbols for architecture x86_64:
  "_g_child_watch_add", referenced from:
      _spawn__processes__do_start_process in spawn-processes__glib.o
  "_g_io_add_watch", referenced from:
      _spawn__processes__do_read in spawn-processes__glib.o
      _spawn__processes__do_start_process in spawn-processes__glib.o
      _spawn__processes__write_standard_input in spawn-processes__glib.o
  "_g_io_channel_set_flags", referenced from:
      _spawn__processes__do_start_process in spawn-processes__glib.o
  "_g_io_channel_shutdown", referenced from:
      _spawn__processes__do_close_pipe in spawn-processes__glib.o
  "_g_io_channel_unref", referenced from:
      _spawn__processes__do_close_pipe in spawn-processes__glib.o

I'm going to dig in :-( Have a good WE, Pascal.

[steve-cs]

Sounds like good progress. I'll take a look at your PR and see if there's something obvious I can do for you.

For Ubuntu, I'm currently installing the libglib2.0-dev package to resolve build, link and runtime dependencies for glib in gps. It might provide clues of what you have to pull in or build for darwin.

[Blady-Com]

The gio lib was missing for spawn lib (I've updated my previous post) thus I've changed:

--- a/gnat/spawn_glib.gpr
+++ b/gnat/spawn_glib.gpr
@@ -57,6 +57,12 @@ library project Spawn_Glib is
            ("spawn-windows_api.ads",
             "spawn-processes-windows.ads",
             "spawn-processes-windows.adb");
+         case Library_Type is
+            when "relocatable" =>
+               for Library_Options use ("-lglib-2.0");
+            when others =>
+               null;
+         end case;

       when "Windows_NT" =>
          for Excluded_Source_Files use Common_Excluded;

All is linking fine now :-) But I've got exceptions when executing gnatstudio:

raised CONSTRAINT_ERROR : erroneous memory access
raised PROGRAM_ERROR : adjust/finalize raised GNATCOLL.VFS.VFS_INVALID_FILE_ERROR: gnatcoll-vfs.adb:340
raised PROGRAM_ERROR : adjust/finalize raised GNATCOLL.VFS.VFS_INVALID_FILE_ERROR: gnatcoll-vfs.adb:340

Have you some on your side?

[steve-cs]

Currently what I see when starting up gnat studio is only one line on the console:

ImportError: could not import gobject (could not find _PyGObject_API object)

I believe this started showing up recently when I moved from Ubuntu Bionic to Ubuntu Focal LTS versions. It's been in the master branch builds for some time. There's some ugly Ubuntu packaging issues related to gi/pygobect and the python2 to python3 migration. And I have been ignoring tracking down and fixing it until Adacore gets gps to run properly on python3.

After that I can create a project and edit (a bunch of errors do show up in the Messages window). When I try to build main.adb I get:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'tool_output' is not defined

So while I'm guessing that I'm getting farther than you on gtk-3.24 branch, it's still broken here. Things might improve if I moved off of wavefront (master). Branches consistent with gtkada 21.2-gtk-3.22.30 or 20.2-gtk-3.22.30 would be the obvious candidates. Probably start with the 21.2 or 20.2 release branches first and see how they behave.

I don't recall ever seeing a CONSTRAINT_ERROR when bringing up GPS. I vaguely remember complaints from GNATCOLL.VFS, but I don't remember what caused or how I fixed them; it could have been years ago.

You knew this wasn't going to be easy.

[steve-cs]

Better news. I forgot that I already had locally built a 21.2-gtk-3.22 version of gps. Commit https://github.com/steve-cs/gnat-builder/commit/a932ae134f44128fe614b90c053b6119cc4ae9cd has now updated my cs-21 branch to now use Adacore 21.2 release branches with gtk-3.22 support and my response to your recent pull request. The resulting gnatstudio thows a lot of GTK warnings on console but basically works on Ubuntu Focal LTS here. It may be useful in separating Wavefront issues from Darwin issues for you.

Edit: Spoke too soon. It did build 7 days ago. The gps build is now failing. I'm preliminarily blaming changes in GCC 11.0.1 Experimental as the Adacore 21.2 sources shouldn't be changing underneath me that much. This is not the first bit of code, tripping more stringent checking in GCC 11.x.

ada_module.adb:52:04: warning: in instantiation at default_preferences-enums.adb:408
ada_module.adb:52:04: warning: use of an anonymous access type allocator
ada_module.adb:84:08: warning: use of an anonymous access type allocator
gtkada-tree_view.adb:903:58: implicit conversion of anonymous access parameter not allowed
gtkada-tree_view.adb:1446:61: implicit conversion of anonymous access parameter not allowed
browsers-call_graph.adb:32:16: warning: no entities of "GPS.Kernel.MDI" are referenced

   compilation of browsers-call_graph.adb failed
   compilation of ada_module.adb failed
   compilation of bookmark_views.adb failed

I'm going to try again ...

[Blady-Com]

Thanks for sharing. On my side here is the CE traceback:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x38)
  * frame #0: 0x00007fff205bdd9b libsystem_pthread.dylib`pthread_mutex_lock + 4
    frame #1: 0x0000000116b481e1 libpython2.7.dylib`PyThread_acquire_lock(lock=0x0000000000000000, waitflag=1) at thread_pthread.h:455:18
    frame #2: 0x0000000116b283bd libpython2.7.dylib`new_threadstate(interp=0x0000000000000000, init=1) at pystate.c:201:9
    frame #3: 0x0000000116b2823a libpython2.7.dylib`PyThreadState_New(interp=0x0000000000000000) at pystate.c:213:12
    frame #4: 0x0000000116b28bdc libpython2.7.dylib`PyGILState_Ensure at pystate.c:604:16
    frame #5: 0x000000010ca6c1f0 libgnatcoll_python.dylib`ada_PyGILState_Ensure at python_support.c:801:16
    frame #6: 0x000000010ca323d0 libgnatcoll_python.dylib`gnatcoll__python__state__initialize__2 at gnatcoll-python-state.adb:32:21
    frame #7: 0x000000010ca69c86 libgnatcoll_python.dylib`gnatcoll__scripts__python__python_backtrace at gnatcoll-scripts-python.adb:4910:7
    frame #8: 0x000000010002cdfe gnatstudio`gps__main__trace_with_python_backtrace.14236 at gps-main.adb:541:55
    frame #9: 0x0000000100017740 gnatstudio`_ada_gps__main at gps-main.adb:3294:7
    frame #10: 0x0000000100070c8d gnatstudio`main at b__gps-main.adb:14920:7

Python lib version 2.7 is called by GnatColl, is it expected? Shouldn't be Python lib version 3.x? GnatColl has two versions :

gnatcoll-bindings-build/python3/python_support.c
gnatcoll-bindings-build/python/python_support.c

I still don't to know how GnatColl select them. Maybe next WE, Pascal ;-)

[steve-cs]

Python lib version 2.7 is called by GnatColl, is it expected? Shouldn't be Python lib version 3.x?

Yes, gps still expects and only works with python 2.7 through gnatcoll-bindings/python. It's not clear where the real python3 support for gps will show up first, in the python or python3 bindings.

Libadalang has moved to python3. GPS was supposed to move python3 by now, but hasn't. The latest status is summarzied in Issue https://github.com/AdaCore/gps/issues/112. Summary: back in December they tried to land python3 support, and it broke stuff quickly and was reverted. I'm waiting for new code and will try as soon as available.

I still don't to know how GnatColl select them.

The python binding looks for "python", and you want the "default" python interpreter to be python2 for gps. The python3 binding looks for "python3". You don't want to build and install both bindings at the same time; that breaks things too. On ubuntu the "python-is-python2" package you should see in base-depends-debian does the symbolic link for me.

Hopefully that makes sense and should be enough to proceed in the upcoming weekend.

[Blady-Com]

Last news: a fix has been pushed in gnatcoll-bindings-python (commit). Thus after building and installing with some changes in gps-runtime-patc, gnatstudio runs :-) However I've got: "ImportError: No module named gi" and the color theme is awful... Well, still lot of work, Pascal.

[steve-cs]

gnatstudio runs :-)

Well done! I remember the first time you said that.

Thus after building and installing with some changes in gps-runtime-patch

Note that in master, I've renamed gps-runtime-patch to gps-install-depends-$(os), so that you can have you're own gps-install-depends-darwin independent of what I may do for debian/ubuntu.

"ImportError: No module named gi"

I've seen that before too. Some minor changes to gi and pyobject dependencies allowed it both build and run without any changes to gps sources. I believe I last ran into it when I was trying to do python3 testing. I was trying to be clever and support both python2 and python3. Something funny in the gi/pyobject dependencies I was pulling in I think. Currently, I don't see it using python2.

Well, still lot of work

I've never tried to change, fix, improve gps itself. So you are about to the end of my direct experience. While I can spin up MacOS in VMware, actual development for a Mac would be stretching my comfort zone.

[Blady-Com]

Last news: I build pycairo and pygobject3 for Python 2 and GNAT Studio runs without errors until now :-) Well, the mouse clic is weird, when clicking in a source code it selects many of lines as shift key was pressed while clicking (text selection)!? PS: I list all used dependancies and their version, if you're interested send me an e-mail: blady.com at wanadoo.fr.

[steve-cs]

Hmmmm, I've seen something like that before. I just checked a local gtk-3.24 gps build from yesterday and it doesn't appear to show that symptom on Ubuntu Focal. I'll build it again now and see if it seems to be related to Adacore changes in the last 24 hours. Otherwise, I'd suspect a version related bug between what I'm pulling in from Ubuntu packages and what you are building directly.