The problem with linking tqt-mt manifests itself only in dcopjava? That would be weird. I would expect that would be equally manifest in other builds using automake.


On Debian builds are successful with Ruby 2.3. A problem that you mention seems that in your case is not defined HAVE_RUBY_1_9. Please check or attach configure log, because this should be defined - see qtruby/rubylib/qtruby/configure.in.in

Aha!  Thanks for that.  I had misconfigured the --with-extra-libs= for the ruby libraries.

But then, when you say Debian was successful building with Ruby 2.3, they must have patched the stock configure files.  I had to patch
tdebindings/qtruby/rubylib/qtruby/configure.in.in
and
tdebindings/korundum/rubylib/korundum/configure.in.in

to extend the tests for Ruby 2.3:

     if test -z "$RUBY_VERSION"; then
       RUBY_VERSION=`$PKGCONFIG ruby-2.3 --modversion 2>/dev/null`
       if test -n "$RUBY_VERSION"; then
         RUBY_CFLAGS=`$PKGCONFIG ruby-2.3 --cflags`
       fi
     fi

This is a bit silly because the same code is repeated for each and every one of ruby 1.9, 2.0, 2.1, 2.2, and now, 2.3.  This is not very scalable, where there is likely to be a ruby 2.4 and on and on.

Patching three files, setting the environment variables, and running with "make -j1", tdebindings builds successfully.

BTW, I notice that the PKGBUILD also applies

 cp /usr/share/aclocal/libtool.m4 ./admin/libtool.m4.in
 cp /usr/share/libtool/build-aux/ltmain.sh ./admin/ltmain.sh

which are from libtool 2.4.6, if that is of interest.

Interestingly, on Debian and Fedora has Ruby 2.3 pkg-config file simply 'ruby.pc' == rule by version number is no longer needed. In any case, it would be a good make the code for testing Ruby better :)

Copy libtool.m4.in and ltmain.sh from the current system is standard basic step for all automake builds. On wiki is mentioned in Building Packages with Autoconf section - see Regenerate Autoconf/Automake files: https://wiki.trinitydesktop.org/How_to_Build_TDE_Core_Modules

Yes, tdebindings is one of the packages for which it is not possible to use a parallel build. It is the same for Debian / Ubuntu. I believe that it is not practical to address this issue == would be preferable to prepare cmake build.

What is the status of this bug?

Sorry - I haven't tried to build this lately.  There does not really exist a proper set of TDE PKGBUILD files for Arch Linux.

I expect that, if nobody has addressed the issues with the tdebindings build, then these problems are still there.  For instance, at
 https://wiki.trinitydesktop.org/How_to_Build_TDE_Core_Modules
"tdebindings" is still not included under "List of Packages Building with cmake".

Creating Arch Linux PKGBUILD files for a fully functioning TDE becomes something of a "layered" challenge, where the core packages must build successfully before the tdebindings build can be attempted.

We might visit this again after R14.0.5.

(In reply to James from comment #5)
> Sorry - I haven't tried to build this lately.  There does not really exist a
> proper set of TDE PKGBUILD files for Arch Linux.
> 
> I expect that, if nobody has addressed the issues with the tdebindings
> build, then these problems are still there.  For instance, at
>  https://wiki.trinitydesktop.org/How_to_Build_TDE_Core_Modules
> "tdebindings" is still not included under "List of Packages Building with
> cmake".
> 
> Creating Arch Linux PKGBUILD files for a fully functioning TDE becomes
> something of a "layered" challenge, where the core packages must build
> successfully before the tdebindings build can be attempted.
> 
> We might visit this again after R14.0.5.

It looks like the tdebinding PKGBUILD for Arch is already ready - you can look at the mirror on TDE Gitea:

https://mirror.git.trinitydesktop.org/gitea/SlavekB/tde-packaging-arch/src/branch/master/R14.0.4/tde-base/tde-tdebindings

Thanks for that Slávek.  I haven't been following for a while:
 https://github.com/michael-manley/Trinity_ArchLinux_PKGBUILD

In answer to Michele, I will point-out Michael's opening build instruction:

"Before installing please remove any presence of JRE and RUBY packages, after install you can put them back."

Michael tends to resolve build problems by disabling Trinity features and functionality, which is a work-around, not a fix, and not very interesting for me.

So I will infer that this bug is still an issue which should be addressed.

Thanks James, I agree with you point of view.

Indirectly related - maybe Trinity wants to move to Meson, instead of CMake?  Just to put the idea on the table.  I don't know if there has already been discussion about this.

James, thank you for your notice in comment 7! I did not look at the Arch builds in detail, but only passively follow their development.

Regarding your comment 9. For now, no one has asked a question about Meson. In any case, there are several facts:

1) In individual parts of Trinity can be found Automake, CMake and Scons. Adding Meson would be another wood in the forest.

2) Major developers are aware of Automake and CMake. Meson we would have to learn from the beginning.

3) At present, individual projects are gradually converted to CMake. It's a slow job, but we are moving forward. Selecting Meson would mean a shift to the beginning.

4) And finally, why should we want Meson?
https://www.rojtberg.net/1481/do-not-use-meson/

I agree with Slavek. Given the resources available and the list of things to do/fix, moving to Meson is not a priority. And there not seem to be a major killer benefit to do so either.
But thanks for raising the point. I didn't know about Meson, so I learnt some new today :-)