Make build more GNU conformant and reproducible #3
Conversation
Most GNU/Linux distributions' packaging build toolchains are centered
around Makefiles that follow GNU Makefile conventions, such as
supporting staged installs (via the DESTDIR variable), for example,
besides honoring {CPP,C,LD}FLAGS.
Other concern modern distributions have regards reproducible builds [1].
To make a build reproducible, the build system needs to be made entirely
deterministic. For example, the current date and time must not be
recorded and output must always be written on the same order.
This patch makes the OpenMRac Linux build more GNU conformant (enough
for the Debian packaging build toolchain) and deterministic, by
appending to *FLAGS instead of overwriting them in the former case, and
by sorting he object file list in the latter.
[1] https://reproducible-builds.org/
There was a problem hiding this comment.
- paths in the deb target might need adjusting as per the updated data path prefix
- also, I believe the deb package would be worth separating into two - executable and data, but I will leave this to a Debian packaging expert (possibly yourself?) and I totally don't require it for this PR to be approved
- I will have to check Debian packages for OpenMRac, if they don't use the deb target, it might be worth removing it altogether.
I will have a look at it. During packaging, we usually make the minimum required changes for the package to build according to Debian Policy. Thus, I hadn't touched other parts of the Makefile (such as the That said, I will try to adjust it as soon as I have spare time.
Oh, it already is. I packaged both openmrac-data and openmrac, which depends on the former.
I didn't use the PS: I posted after you had merged the PR :). Thanks! |
|
Please check my latest commit if it seems roughly OK (i.e. I didn't break anything vital for Debian packaging). Thanks. |
LGTM. Now that we are using About the openmrac-es2 package, I don't think it is needed. For instance, in my desktop PC, I can select between OpenGL Compat. profile, OpenGL ES 2 and OpenGL 3.3 from the settings dialog, and it works with OpenGL ES 2 just fine. If an ARM user whishes, they can install the required OpenGL ES 2 runtime support libs without the need to change anything. Maybe that could be told in the README? |
|
Concerning ES2 support package, I am unfamiliar with the methods you are describing. The Makefile.linux-es2 links against libGLESv2 instead of libGL which makes it foolproof IMO. Also, there are slight tweaks to shaders and GL functions too, the two libraries don't map 1:1. The package idea was inspired by e.g. https://manpages.ubuntu.com/manpages/focal/man1/glmark2-es2.1.html As an example of SBC issues, many games linked against libGL run badly or crash right away on StarFive VisionFive 2 provided Debian image. On the other hand, OpenMRac built with Makefile.linux-es2 ran fine. I believe Desktop GL with ES2 profile and linking to actual ES2 library are two different things. Let's keep this question pending for now. |
You're right. I didn't think enough about it as I was answering your comment. I will think about that approach when I manage to get some time to work on it. |
Most GNU/Linux distributions' packaging build toolchains are centered around Makefiles that follow GNU Makefile conventions, such as supporting staged installs (via the DESTDIR variable), for example, besides honoring {CPP,C,LD}FLAGS.
Other concern modern distributions have regard reproducible builds [1]. To make a build reproducible, the build system needs to be made entirely deterministic. For example, the current date and time must not be recorded and output must always be written on the same order.
This patch makes the OpenMRac Linux build more GNU conformant (enough for the Debian packaging build toolchain) and deterministic, by appending to *FLAGS instead of overwriting them in the former case, and by sorting he object file list in the latter.
[1] https://reproducible-builds.org/