Asdf: Plugin Implementation Questions

Created on 26 Apr 2020  路  4Comments  路  Source: asdf-vm/asdf

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.

Build configuration options

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?

Shim Includes and Libs

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:

  1. I could maybe add the 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".
  2. In the documentation 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.
  3. There is the 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.

Most helpful comment

@jthegedus Great, nice one. sure, I'm happy to take a look.

All 4 comments

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.

re: Build configuration options

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.

re: Shim includes and libs

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.

Build configuration options

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.

Shim includes and libs

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:

to 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michalmuskala picture michalmuskala  路  5Comments

Antiarchitect picture Antiarchitect  路  3Comments

ypid picture ypid  路  3Comments

point-source picture point-source  路  4Comments

niksfirefly picture niksfirefly  路  3Comments