[Octave-bug-tracker] [bug #60695] Presence of qtchooser in host system breaks build with Qt in another prefix (pkgsrc here)

[anonymous]

Follow-up Comment #2, bug #60695 (project octave):

Hm, I hoped reply-by-mail works. Here is my comment I sent before:

My M4-foo is not well-trained. Would it be feasible to have it always
generate an absolute path to the Qt tools and then do

test `readlink "$MOC"` = qtchooser

(or a safer variant that also checks for */qtchooser or such)?

Readlink of course doesn't work with the tool command is just `uic`.

About chooser config for the custom version: There are several reasons,
but the strongest might be these two:

1. Non-root users can install a tree via pkgsrc/conda/whatever, but
they have no power over system qtchooser config or might install Qt for
other users to use, so have no power over any custom config. They can
offer environment modules that add to PATH and friends, though.

2. Envrionment modules mean that there is run-time switching of
software trees via PATH-like variables. I do not know if the qtchooser
configuration fits that, unless a qtchooser is installed in each tree.

I must admit that I never stumbled over the qtchooser behaviour before.
It is one approach to work with differing trees of software, specific
to Qt in this case. Managing PATH via environment modules is another
way, generic to loads of software.

My most active time of intentionally building Qt was back with KDE 3.
Now I just wanted to build Octave from pkgsrc and it broke with the
recent update. As long as the qtchooser thing is no requirement, just a
nice add-on for binary distros, it would be nice if pointing PATH (and
PKG_CONFIG_PATH, etc.) to another install still works.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60695>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/