Hi,
I started to put together a plugin for QT (here). Got things to be working for the most part, but had a couple of outstanding things I'd like to clean up. I was looking to see if there are any patterns people are already using to handle these things.
QT has some build options that I'd like to expose to cut down on the compile times. At the moment my plan I think my only option is to have these provided by plugin specific design variables - something like this:
$ ASDF_QT_CONFIGURE_OPTIONS="-skip qtconnectivity -no-feature-accessibility" asdf install qt 13.2.1
Though maybe it would be nicer to be able to be able to transparently pass them to my bin/install script. Something like:
$ asdf install qt 13.2.1 -skip qtconnectivity -no-feature-accessibility
I'm not familiar with bash, but I think that maybe I would loose scope of these arguments by the time my bin/install script is ran. Is that correct?
Looking at the qt brew formula caveats, they suggest to point your LDFLAGS CPPFLAGS at the lib and include folders.
$ brew info qt
...
For compilers to find qt you may need to set:
set -gx LDFLAGS "-L/usr/local/opt/qt/lib"
set -gx CPPFLAGS "-I/usr/local/opt/qt/include"
...
With asdf we'd want for this path to be able to be shimmed as well, so if can dynamically change with the selected version. Is there a suggest method to handle this?
I've seen a few things that look like they might be the solution:
lib and include folders into the shims, if you can do that with directories and not just binaries. e.g. LDFLAGS="-L~/.asdf/shims/qt/lib".haxe is shouted out as using extension commands to link dynamic libraries. I'm not sure if this is exactly the same problem, or from reading the haxe source who it behaves and if it needs the user to not only switch the version but remember to invoke a separate command after.asdf env <cmd> command. But I'm not overly sure what the intended escape of this is from the documentation. So I assume this might work where if you are invoking a command that expects these environment variables set you'd run it via this asdf env command, so asdf env qt make . where make would now have the LDFLAGS, and CPPFLAGS exported for it before invoked.Hi @jamesstidard thanks for raising this, I am working on an update to the "create plugin" docs atm and will add the output of this discussion to the docs for future reference.
I would look at the asdf/asdf-* plugins or the plugins from the asdf core team to see if any of these set build options. I imagine one of their plugins has dealt with this before (I vaguely recall reading something like this). Maybe it was the erlang or elixir plugins.
Not a complete answer, but perhaps bin/exec-env is one solution to this problem. Or if not that, something similar to the JAVA_HOME solution in the asdf-java plugin https://github.com/halcyon/asdf-java/issues/51 (solution scripts in their README)
Hi @jthegedus, I appreciate the response - especially as my initial post was quite long and rambling.
Ah, I did look through a number of plugins to see if I could find any that had something like this but didn't find any. You are right, asdf-erlang does the environment variable approach. I'll go with that one.
Ah thank you for the link. I didn't I clocked from the plugin documentation that this was the behaviour that bin/exec-env had. This seems like exactly what I was after. The thread you link references this which clarified it for me. Maybe if you're working on that update to the docs this is something to incorporate / reference in the bin/exec-env section
Thanks again for the pointers. I'll have a go at adding those changes.
@jamesstidard I'm glad you found that helpful. And your question wasn't rambling :smile:
I will add:
asdf install example and links to examplesbin/exec-env clarification and combination with the asdf exec usage described in https://github.com/asdf-vm/asdf/blob/master/docs/core-manage-versions.md#shimsto the list of improvements I am making to the docs.
Are you open to me tagging you to review the changes I may make?
@jthegedus Great, nice one. sure, I'm happy to take a look.
Most helpful comment
@jthegedus Great, nice one. sure, I'm happy to take a look.