[casadi] first step (no dependencies)

[jgillis]

• Changes comply with the maintainer guide.
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

[jgillis]

@microsoft-github-policy-service agree company="yacoda"

[dg0yt]

It might be more practical to format the portfile with spaces, not tabs. (Tabs are subject to settings. GH PR review looks strange.)

I see a lot of find modules. I would expect a similar set of dependencies in the manifest.

[dg0yt]

If it is only about dllexport:

Suggested change

	vcpkg_check_linkage(ONLY_DYNAMIC_LIBRARY)
	if(VCPKG_TARGET_IS_WINDOWS)
	vcpkg_check_linkage(ONLY_DYNAMIC_LIBRARY)
	endif()

[dg0yt]

Maybe put the PR in draft state as long as it is not ready for review.

[jgillis]

@dg0yt Thanks for your review, I assumed you would not start a review while CI still runs..

CasADi works with a plugin system.
The core is basically dependency-free.
In this first version, I'm packaging the 'core' feature set.
Next up would be coin-or-ipopt dependency, but that's for another PR.
Because of the plugin system, static libraries do not currently make sense.

I'll think about adding the namespace upstream.

[jgillis]

@dg0yt The CI checking seems to stall; x64_linux is compiling whole of llvm, and windows builds queue until timeout.
Is this a normal state of affairs or am I just unlucky?

[dg0yt]

CI has a real problem.
llvm:x64-linux is building because the PR touches ci.baseline.

[jgillis]

Oh I see, thanks for helping out this vcpkg noob.