Rebuild package when Gurobi installation changes

[sebastianangerhausen]

Right now, when you update your local installation of Gurobi after having built Gurobi.jl, you need to execute build.jl again in order to update the libgurobi constant. This can be automated by making libgurobi non-constant, checking if the library can be loaded, and (if needed) re-run build.jl.

[odow]

I would prefer that we updated the README to clarify the need to rebuild if you change your local installation.

I also hope that we can move most people to Gurobi_jll, so they shouldn't need to provide a manual installation.

Thoughts?

[sebastianangerhausen]

Ok, I'm fine with that.

I would like to use Gurobi_jll, but I am facing two issues here:

1. Importing Gurobi.jl using using Gurobi or import Gurobi takes significantly longer when using Gurobi_jll instead of the local installation.
2. Gurobi_jll seems to respect the environment variables at the time when the package is imported (by importing Gurobi.jl). However, sometimes I need to dynamically change the location of the license file by modifying ENV["GRB_LICENSE_FILE"] at runtime. I couldn't find a way to do this after loading Gurobi.jl.

[odow]

significantly longer

How much longer?

sometimes I need to dynamically change the location of the license file by

Why do you want to do this? Does it really work with a manual installation? We aren't doing anything different with Gurobi_jll, and the Julia code doesn't store or use the location of the license file anywhere.

[odow]

In a fresh environment, Gurobi_jll adds 381 ms to the loading time:

julia> @time_imports using Gurobi
     15.0 ms  Preferences
      0.9 ms  JLLWrappers
               ┌ 351.0 ms Gurobi_jll.__init__() 6.10% compilation time
    381.6 ms  Gurobi_jll 13.24% compilation time
               ┌ 6.4 ms SuiteSparse_jll.__init__() 
      7.4 ms  SuiteSparse_jll
               ┌ 6.7 ms SparseArrays.CHOLMOD.__init__() 90.78% compilation time
    173.7 ms  SparseArrays 3.48% compilation time
     32.4 ms  Test
    141.9 ms  MutableArithmetics
      4.2 ms  OrderedCollections
      0.7 ms  PrecompileTools
               ┌ 0.0 ms Parsers.__init__() 
     40.2 ms  Parsers
     11.8 ms  JSON
      1.5 ms  Statistics
               ┌ 0.0 ms Profile.Allocs.__init__() 
     47.4 ms  Profile
      4.1 ms  BenchmarkTools
      5.9 ms  IrrationalConstants
      1.7 ms  DiffRules
      1.3 ms  StaticArraysCore
      1.3 ms  DiffResults
               ┌ 1.6 ms OpenLibm_jll.__init__() 
      2.5 ms  OpenLibm_jll
      0.8 ms  NaNMath
               ┌ 0.0 ms DocStringExtensions.__init__() 
      1.9 ms  DocStringExtensions
      0.9 ms  LogExpFunctions
               ┌ 21.2 ms CompilerSupportLibraries_jll.__init__() 23.49% compilation time
     22.4 ms  CompilerSupportLibraries_jll 22.21% compilation time
               ┌ 1.3 ms OpenSpecFun_jll.__init__() 
      3.3 ms  OpenSpecFun_jll
      8.6 ms  SpecialFunctions
     10.7 ms  MacroTools
      0.9 ms  CommonSubexpressions
     41.9 ms  ForwardDiff
      1.3 ms  Compat
      0.7 ms  Compat → CompatLinearAlgebraExt
     25.2 ms  DataStructures
      2.9 ms  TranscodingStreams
      0.8 ms  TranscodingStreams → TestExt
               ┌ 1.0 ms Bzip2_jll.__init__() 
      2.1 ms  Bzip2_jll
      1.1 ms  CodecBzip2
               ┌ 1.8 ms Zlib_jll.__init__() 
      2.8 ms  Zlib_jll
      1.5 ms  CodecZlib
    695.4 ms  MathOptInterface
     22.9 ms  Gurobi

[odow]

How is #567?

[sebastianangerhausen]

How much longer?

Almost a minute:

Why do you want to do this? Does it really work with a manual installation? We aren't doing anything different with Gurobi_jll, and the Julia code doesn't store or use the location of the license file anywhere.

I used to handle different app names for the cluster manager by using different license files. However, this can be easily solved by modifying the respective parameter using GRBsetstrparam for the parameter CSAPPNAME. So the main issue is the import time.

[odow]

Something is wrong with the import time. That's a bug we should fix.

What is the output of versioninfo()? What machine is this? How did you install Julia? Is it a managed machine for work? Perhaps it is some antivirus scan? Could you look at a task manager to see what is happening during the import?

[odow]

So I'm going to guess this is a Windows machine.

If so, try ] add Gurobi_jll#odow-patch-2. Restart Julia, and then try loading Gurobi again.

[sebastianangerhausen]

Looks better now:

[odow]

Great! Closing in favor of jump-dev/Gurobi_jll.jl#22 (and also partially fixed by #567)

I'll get a fix tagged ASAP.

Thanks for reporting this. I don't have a Windows machine so I would't have noticed 😄

[odow]

Once JuliaRegistries/General#109241 is merged it should work after updating.