[ports/ed25519/CMakeLists.txt] Install all headers

[SamuelMarks]

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Not sure if I'm meant to manually change "port-version": 0?

Anyway these headers all need to be installed as some packages, for example, depend on ge.h so that needs to be installed.

[JonLiu1993]

@SamuelMarks, thanks for your PR, plesase also add "port-version: 1" to vcpkg.json file.

[dg0yt]

ed25519:x64-linux:/include/ed25519.h
ed25519:x64-linux:/include/fe.h
ed25519:x64-linux:/include/fixedint.h
ed25519:x64-linux:/include/ge.h
ed25519:x64-linux:/include/precomp_data.h
ed25519:x64-linux:/include/sc.h
ed25519:x64-linux:/include/sha512.h

Not acceptable. Some filepaths (e.g. include/sha512.h) shouldn't be owned by this port.
It might be possible to move the private headers to a s subdir, but does it help those consumers?

[JonLiu1993]

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

[SamuelMarks]

@dg0yt @JonLiu1993 How about just these four headers?

Otherwise will have to figure out a pretty big patch file to namespace everything here; and another patch to namespace everything in the callee library (that I don't maintain).

[dg0yt]

Hm, I'm still mildly opposed to putting private headers into the main include dir, for one unknown use case.
But someone else must decide.

[JonLiu1993]

Hm, I'm still mildly opposed to putting private headers into the main include dir, for one unknown use case. But someone else must decide.

@SamuelMarks, One thing I'm sure of is that if you want to add a private header file in the main include dir, you need to get the author's permission from upstream.

[dg0yt]

There are two separate questions:

• whether to install private headers: upstream.
• whether to install particular files directly to include: integrator (vcpkg).

[JonLiu1993]

Ping @SamuelMarks for response.

[SamuelMarks]

I've limited the included headers to 4. If you want it to be namespaced ask?

[JonLiu1993]

I've limited the included headers to 4. If you want it to be namespaced ask?

@SamuelMarks, You can ask the upstream if it agrees to install the private header file?

[JonLiu1993]

This upstream repository is unmaintained, and issues submitted upstream have not been responded to for a long time, so I think we can merge this PR.

[JonLiu1993]

@SamuelMarks, please merge this PR to master, thanks.

[SamuelMarks]

@JonLiu1993 Did that yesterday

[vicroms]

@SamuelMarks

We took a look at the headers and noticed that the public API is contained to just ed25519.h. All other headers contain only private implementation details and should not be installed.

You mentioned that some packages require ge.h, what packages do you mean exactly? and why do they need access to the private implementation details?

[vicroms]

Suggested change

	install(FILES "src/ed25519.h" "src/fe.h" "src/fixedint.h" "src/ge.h" DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")
	install(FILES "src/ed25519.h" DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}")

[SamuelMarks]

@vicroms That's what I had before; but the library I am integrated vcpkg into uses these other headers directly and I don't want to edit their codebase [source or header files] in order to support the platforms vcpkg supports.

[dg0yt]

There is still the suggestion to put the private headers into a unique subdir. This is one change for that project (to use an additional include dir), instead of having the private headers in everybody's search path.
(And for specific single-user requirements, their are overlay ports and other customization points.)

[vicroms]

The vcpkg team agrees with @dg0yt's points:

• Moving the private headers into a subdirectory (e.g.: orlp-ed25519/*.h) would be acceptable.
• Forcing other users to deal with the consequences of a project deciding to take a dependency on private headers not meant for consumption is not acceptable.
• Users can override the behavior by using overlay ports with the changes you have made here.

Please let me know if this resolution is acceptable to you.