Added builder for ASL2

[cvanaret]

close #11158

Derived from https://github.com/JuliaPackaging/Yggdrasil/tree/master/A/ASL

ASL2 (AMPL Solver Library 2) is an alternative to ASL that is thread-safe and uses evaluation workspaces.
See documentation (look for solvers2) and sources.

cc @dpo @amontoison

[ViralBShah]

cc @odow

I also wonder if both ASL and ASL2 should live in A/ASL (as in A/ASL/ASL and A/ASL/ASL2).

[odow]

@amontoison what are the implications if Uno builds with ASL2 but Ipopt builds with ASL?

[amontoison]

@odow It will not be an issue as long as the symbols are not loaded in a global namespace (dlopen with RTLD_GLOBAL).

But we don't do that in Julia:
https://github.com/JuliaBinaryWrappers/ASL_jll.jl/blob/main/src/wrappers/x86_64-linux-gnu.jl#L11

So the two libraries will not get the symbols of their dependencies colliding.
libipopt.$dlext --> libasl.$dlext
libuno.$dlext --> libasl2.$dlext

We can have an issue if a solver links to both libasl.$dlext and libasl2.$dlext, but I don't think it makes any sense to do that...

What I am more scared about with this PR is that the C interface was developed as a patch by Dominique a long time ago, and I don't know if it is still compatible.

That is why I never updated ASL_jll.jl: it may break AmplNLReader.jl, and also all JLLs with an AMPL interface.
I don't know if any breaking change happened since build 0.1.3.
The versioning seems nonexistent, and I don't know where to find the changelog.
From what I understand, a new .tgz archive is sometimes uploaded on the Netlib website.
I heard that they fixed bugs with complementarity constraints, but I'm too scared to do anything.

I suggest that we check with David Gay by email before we merge anything.

[odow]

An alternative: Charlie could just vendor this into Uno? I'm also not keen on touching the current ASL. I've never had any bug reports about it.

[amontoison]

We also don't need the C interface developed by Dominique if we do that (bundled/asl-extra).
It is already shipped by libasl.$dlext in ASL_jll.jl.

Charlie, can you use a GitSource (https://github.com/ampl/asl)
instead of the ArchiveSource here?

I found that the version is in the commit with a small changelog.
Example: ampl/asl@3d477ba
The version of the JLL ASL2 should be 2025.11.21 if we use the most recent commit.

[cvanaret]

I just pushed a draft with GitSource instead, and got rid of the bundled directory. Let me know if that works for you.

[cvanaret]

We're good to go. I had to fix a couple of issues on the asl side. I'll clean up the build_tarballs when this is patched upstream.

[imciner2]

This appears to be building both a libasl and libasl2. I am not sure having that libasl in this JLL is wise if we want to keep the other ASL JLL package. I am not sure if having it here would confuse the binary loaders by having it in two separate JLL packages. Does libasl2 need libasl at all, or could it be removed/not-built?

[cvanaret]

Good point. libasl and libasl2 are independent, but both are built by default. We'd have to hack their CMakeLists with a sed command. I'll give it a try tomorrow.

[amontoison]

Good point. libasl and libasl2 are independent, but both are built by default. We'd have to hack their CMakeLists with a sed command. I'll give it a try tomorrow.

I suggest something less hacky:

rm $libdir/libasl.$dlext
rm -r $includedir/asl

And also on Windows platforms:

rm $prefix/lib/libasl.dll.a

@imciner2 Is it normal that we have a folder with cmake files in share ?
The subfolder is ampl-asl.

[imciner2]

@imciner2 Is it normal that we have a folder with cmake files in share ?
The subfolder is ampl-asl.

Yep, that is one of the folders that the CMake scripts for find_package can be located. So it will be installed automatically by their build system. If there is one for libasl, that will also need to be deleted along with the library.

That CMake file appears to have parts for both ASL and ASL2, so if you just delete the libasl libraries, the CMake will then fail because it checks they are existing for the asl target. The best way to handle this is really to disable the asl build in the source CMake.

[cvanaret]

I have disabled the asl build and deleted include/asl.

[cvanaret]

Gentle bump :)

[ViralBShah]

@amontoison The github repo has v1.0.1 - so shouldn't we just go with 1.0.2 or something if we are using a recent commit - rather than going with the 2025.x.y (which will permanently have us out of sync with the upstream)?

[amontoison]

@ViralBShah The version v2025x.y is the version upstream. You need to check the description of the commits to get it and not the releases on their github repository.

[ViralBShah]

@amontoison Ok - thanks. Shall we merge?

[amontoison]

Yes, LGTM 👍

[amontoison]

@imciner2 All good for you too?