I try to compile a project into an application that depends on Tulip.jl, but the resulting App is not portable, see:
Has someone managed a similar situation and has some advice.
Is it possible to handle this missing relocatibility inside my project or is it necessary that this issue need to be handled inside the conflicting package Tulip.jl?
Thanks for the idea with __init__()!
I found the function __init__() in the project Tulip.jl does it make sense to fork the project and add something myself into this function?
And if so, can someone suggest a good example what and how to do this?
The problem is not the content of function __init()__.
The package Tulip is not even listed in the Project.toml of the project that I try to compile into a portable application. One of the packages used relay on it.
The main issue is the missing Relocatibility of Tulip.jl …
@fredrikekre & @mkitti
First of all thank you for your help!
It was haphazardly that I included the function Tulip.__init__() in my minimal example
and it was not obvious to me that this was already the part of the Tulip-code that causes the trouble.
Ok, I understand the root cause of my problem. Consistently, I have added my local clone of Tulip.jl as development package to the primary environment, but this does not cure the problem
During package compilation the standard Tulip.jl is taken to build the library “sys.dll”.
Is there a way to specify the local Tulip.jl-package to be utilized during package compilation?
You would want to create specific environment for your project, and then dev your local copy into that environment. I would not recommend using the default primary environment (e.g. @1.8 or @1.9) for this purpose. In fact, I would consider backing up that primary environment (copy the Project.toml and Manifest.toml) and clearing it out to make sure it does not interfere with system image building. Then, I would activate an environment in a local folder and add exactly the packages you need via Pkg.add or Pkg.dev.
To clarify, Tulip.__init__() will be invoked the first time your code does using Tulip.
Thanks, for the idea! - It seems that the PackageCompiler is a little bit an anarchist, …
Meanwhile I did exactly this. I established my own primary environment and added the local clone of Tulip in this private primary environment. And started in this environment the process create_app().
But PackageCompiler took again the wrong version of Tulip
Just to make sure, consider bumping the version number of your Tulip.jl clone and make sure that version is added to the environment. Another consideration, is to create a git branch, commit your changes, and add it via add /path/to/Tulip.jl#branchname.
Meanwhile, the package maintainer of Tulip.jl agreed to publish a new version.
Therefore, the Tulip-issue might be resolved soon.
But the topic / question remains:
How can I specify, which version of a package (a local development version or a registered one) is going to be taken for the compilation.