[base64] Add new port

[BurningEnlightenment]

Describe the pull request

• What does your PR fix?

  Fixes [New Port Request] base64 #25090

• Which triplets are supported/not supported? Have you updated the CI baseline?

  all, No

• Does your PR follow the maintainer guide?

  Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  Yes

TODO list

• The patch is currently being upstreamed in [cmake] Install all RUNTIME targets into bin/ aklomp/base64#89
• Await release of version 0.5.0 containing the CMake buildsystem Create release 0.5.0 aklomp/base64#90

[PhoebeHui]

@BurningEnlightenment, thanks for your PR! feel free to ping us if the PR is ready for review.

[BurningEnlightenment]

Will do, I'm currently waiting for upstream to fix the last issue and to official release 0.5.0 this may take another week or two

[Adela0814]

@BurningEnlightenment Is work still being done for this PR?

[BurningEnlightenment]

The 0.5.0 release has been delayed due to a critical bug affecting code generation for Apple's M1 architecture. We cannot properly use the 0.4.0 release due to lack of a cmake project and Windows issues. So either we add an unoffcial prerelease version or wait until things have been sorted out upstream. Sorry for the inconveniences.

[Adela0814]

Closing this PR. Please reopen it if it is no longer blocked.

[BurningEnlightenment]

@Adela0814 The release finally happened and I updated the port. Can you reopen this or do I need to submit a new PR?

[Adela0814]

If this PR is ready for review, please feel free to reopen it.

[BurningEnlightenment]

@Adela0814 I don't have a button to reopen it. I guess that I am missing rights to do it and a maintainer has to reopen it.

[BurningEnlightenment]

@Adela0814 thanks. This is ready for review now.

[BillyONeal]

I'm concerned about the names this port wants stepping on things that are already taken. In particular:

modp-base64:x64-linux:/debug/lib/liblibmodpbase64.a
modp-base64:x64-linux:/include/modp_b64.h
modp-base64:x64-linux:/lib/liblibmodpbase64.a
turbobase64:x64-linux:/debug/lib/libbase64.a
turbobase64:x64-linux:/include/turbob64.h
turbobase64:x64-linux:/lib/libbase64.a
turbobase64:x64-linux:/share/base64/base64Config-release.cmake
turbobase64:x64-linux:/share/base64/base64Config.cmake
live555:x64-linux:/include/Base64.hh

Is the port trying to take any of these names?

It's also concerning that "base64 library c++" doesn't include this library anywhere even on the first page. Would you be willing to accept renaming to aklomp-base64 instead?

[BillyONeal]

Indeed:

bion@BION-TR:~/vcpkg$ ./vcpkg install base64
Computing installation plan...
The following packages will be built and installed:
    base64[core]:x64-linux -> 0.5.0
Detecting compiler hash for triplet x64-linux...
Restored 0 package(s) from /home/bion/.cache/vcpkg/archives in 5.591 us. Use --debug to see more details.
Installing 1/1 base64:x64-linux...
Building base64[core]:x64-linux...
-- Using cached aklomp-base64-9ae5ad37720bc94e90719566de48e2444b96b642.tar.gz.
-- Extracting source /mnt/c/Dev/vcpkg-downloads/aklomp-base64-9ae5ad37720bc94e90719566de48e2444b96b642.tar.gz
-- Using source at /home/bion/vcpkg/buildtrees/base64/src/444b96b642-5dd27aa75a.clean
-- Configuring x64-linux
-- Building x64-linux-dbg
-- Building x64-linux-rel
-- Installing: /home/bion/vcpkg/packages/base64_x64-linux/share/base64/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "/home/bion/.cache/vcpkg/archives/bb/bbd78b9528f6cd67b6760712f878f5c7e2c25188e3d1d0ea23107fd6342b899a.zip"
The following files are already installed in /home/bion/vcpkg/installed/x64-linux and are in conflict with base64:x64-linux

Installed by turbobase64:x64-linux
    debug/lib/libbase64.a
    lib/libbase64.a

Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+base64
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[base64]+Build+error
Include '[base64] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
    vcpkg-tool version: 2022-07-21-a0e87e227afb536c62188c11ad029954f28fdb22
    vcpkg-scripts version: ee6c48459 2022-08-22 (12 hours ago)


bion@BION-TR:~/vcpkg

[BurningEnlightenment]

@BillyONeal I feared as much regarding name clashes with other libraries. I'm open wrt changing the directory layout and/or port naming as long as the cmake configs and targets stay compatible. What would be your suggestion for the library name clash? A subdirectory?

It's also concerning that "base64 library c++" doesn't include this library anywhere even on the first page. Would you be willing to accept renaming to aklomp-base64 instead?

It does come up second place if you search for base64 c simd and it got way more stars on github than turbobase and lemires base64 implementation combined (as can be seen by this search querry: base64 simd).

[BillyONeal]

@BillyONeal I feared as much regarding name clashes with other libraries. I'm open wrt changing the directory layout and/or port naming as long as the cmake configs and targets stay compatible. What would be your suggestion for the library name clash? A subdirectory?

Given linkers' behavior I think the name of the lib needs to change :(. Yes, upstream may hate this :( :(

It's also concerning that "base64 library c++" doesn't include this library anywhere even on the first page. Would you be willing to accept renaming to aklomp-base64 instead?

It does come up second place if you search for base64 c simd and it got way more stars on github than turbobase and lemires base64 implementation combined (as can be seen by this search querry: base64 simd).

Sure but we aren't talking about a port named base64-simd, we're talking about one named base64, so I don't think adding simd is fair.

[BurningEnlightenment]

I'm a bit undecided, but I will probably retract this port. I should be fine adding the port to my own registry as is, since using turbobase is a showstopper for me due to its GPL license. However, I intend to ask upstream whether they are willing to refrain from grabbing common names (claiming C mangled function names like base64_encode seems a bit risky, too).

Regarding

turbobase64:x64-linux:/lib/libbase64.a
turbobase64:x64-linux:/share/base64/base64Config-release.cmake
turbobase64:x64-linux:/share/base64/base64Config.cmake

The turbobase port uses a custom CMake buildsystem instead of the upstream autotools based one. So shouldn't these paths be

turbobase64:x64-linux:/lib/libturbobase64.a
turbobase64:x64-linux:/share/turbobase64/turbobase64Config-release.cmake
turbobase64:x64-linux:/share/turbobase64/turbobase64Config.cmake

instead? Or has that ship sailed due to backward compat?

[BillyONeal]

Regarding

turbobase64:x64-linux:/lib/libbase64.a
turbobase64:x64-linux:/share/base64/base64Config-release.cmake
turbobase64:x64-linux:/share/base64/base64Config.cmake

The turbobase port uses a custom CMake buildsystem instead of the upstream autotools based one. So shouldn't these paths be

turbobase64:x64-linux:/lib/libturbobase64.a
turbobase64:x64-linux:/share/turbobase64/turbobase64Config-release.cmake
turbobase64:x64-linux:/share/turbobase64/turbobase64Config.cmake

instead? Or has that ship sailed due to backward compat?

I think that would be a reasonable change (the ship has not sailed IMO).

[dg0yt]

I think that would be a reasonable change (the ship has not sailed IMO).

In that case, it should be moved to the unofficial namespace.
Btw. turbobase64 isn't used anywhere in vcpkg.

[BurningEnlightenment]

I decided to migrate the port to my registry and put this PR on hold until upstream makes a decision wrt its naming.

@BillyONeal I'm wondering: Is there some protocol/guideline for ports changing names? llfio might get renamed to llio in the foreseeable future...

[BillyONeal]

@BillyONeal I'm wondering: Is there some protocol/guideline for ports changing names? llfio might get renamed to llio in the foreseeable future...

We end up having to leave the old name and make it an empty port that has a dependency on whatever the new name is. We've done it but we try to avoid doing so for hopefully apparent reasons :)