[libxmp] add new port

[dbarkar]

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

[FrankXie05]

I need to test these features and wait for the CI check to finish.

[FrankXie05]

The features and usage have been tested successfully locally.

[BillyONeal]

Thanks for the new port!

[BillyONeal]

This broke in CI because it conflicts with the existing port, libxmp-lite. It looks like libxmp[core] is equivalent to libxmp-lite; should we just delete the old port and point customers at this one?

I note that sdl2-mixer has a find_dependency(libxmp-lite) which suggests cmake configs might be different?

[BillyONeal]

/cc @Ghabry You added the original libxmp-lite port back in 2017, does changing to use this one make sense?

[JackBoosY]

Also, the source downloaded from sourceforge is far outdated than the one on github:

[HunterZ]

Also, the source downloaded from sourceforge is far outdated than the one on github

I was worried about the same thing, but then I noticed that @dbarkar (who opened this issue) has also recently contributed to the libxmp github repo. I'm therefore assuming that vcpkg is building the github source and not older, apparently abandoned sourceforge source.

[dbarkar]

I just tried to build latest libxmp-lite from github and it is still in conflict with libxmp - they both install xmp.h.

Also, libxmp-lite lite will be deprecated in future - libxmp/libxmp#387.

should we just delete the old port and point customers at this one?

I suggest to do so :)

[JackBoosY]

I just tried to build latest libxmp-lite from github and it is still in conflict with libxmp - they both install xmp.h.

Yeah it should always have conflicts.
Can we build libxmp-lite from libxmp source? If it's yes, which cmake options should we pass into vcpkg_cmake_configure?

Also, libxmp-lite lite will be deprecated in future - libxmp/libxmp#387.

should we just delete the old port and point customers at this one?

I suggest to do so :)

Yeah so we prefer to remove this port.
But instead of this, we can also simply add feature lite to libxmp and point libxmp-lite to libxmp[lite] feature.

[dbarkar]

Can we build libxmp-lite from libxmp source? If it's yes, which cmake options should we pass into vcpkg_cmake_configure?

It would require to use different CMakeLists.txt, from lite directory. Will it work for vcpkg?

[JackBoosY]

Can we build libxmp-lite from libxmp source? If it's yes, which cmake options should we pass into vcpkg_cmake_configure?

It would require to use different CMakeLists.txt, from lite directory. Will it work for vcpkg?

When I checked the CMakeLists of libxpm and libxpm-lite, I thought the solution I said earlier was unreasonable:

• If the library generated by libxmp-lite will always conflict with the library generated by libxmp, we can't install both library files at the same time (the conflict will happen in the msbuild integration).
• We had to make a huge patch of cmakelists to do all of this request.

So, I think we should remove this port again, do you agree this?

[dbarkar]

I agree.
Users of xmp-lite can use xmp without depackers and loaders (exposed as features). It wouldn't require changes in the code.

[Ghabry]

I'm fine with removing xmp-lite.

The reason why I havn't bumped xmp-lite yet is, that there is still no released version of the library with official CMake support in the upstream repo.

There is only one when you use the main/master branch directly as you did. Thanks for this.

---

The main reason why I use "xmp-lite" is the license. lite is MIT I think and xmp is LGPL.

Will suggest to upstream to have this as a build type option, then it can be a feature opt-in. (what @JackBoosY suggested)

[BillyONeal]

Thanks folks!