flac dev - Sep 2022 - Enabling universal building of libFLAC

Op zo 18 sep. 2022 om 16:06 schreef brianw <brianw at audiobanshee.com>:
> When you refer to "runtime variables," do you really mean build
time?
>
Yes, build time. That was formulated wrong.

I would assume that the source code does not need to change in order
to
> support multiple architectures on macOS, but the compiler and/or make
> options may need to change.

What I mean by changing code is mostly changing preprocessor defines.
Certain code is included or excluded from compilation by the preprocessor
based on defines that use variables set or unset by the configure or CMake
configuration. However, if these decisions need to be made at build time
instead of at configuration time for MacOS, these preprocessor defines
needs to change, hence the source code needs to change.

It might be possible to not touch the code by solving this in config.h for
CMake. In CMake config.h one can add conditional statements. I'm unsure
whether that is also possible for configure.

One could choose to support universal building only through CMake, as this
seems to easier to solve.

> I have not dug into the details yet. If someone does not find a solution
> before I get back from vacation, I'll take a look. Usually, Xcode makes
> this easy, and Xcode even produces a Makefile that works outside of the GUI
> Xcode.app (i.e. it supports command-line building), so that might be a
> reasonably quick option. However, I admit that keeping Xcode files up to
> date - like any other GUI build environment - might not be worth the
> effort, but at least the Makefile could be useful.
>
It could be such a Makefile provides clues on how and where to change the
build system as it is, yes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220918/86cf2349/attachment.htm>

Ah, yes, the preprocessor defines. Now I see what you're talking about.
Those are crucial because there is often code specific to a particular
architecture.

NeXT and Apple have supported up to four-processor multi-architecture builds
since the nineties. I don't know whether they modified the compiler to do
this, or what. But the standard practice is to learn the #define values that
signal a specific architecture, and work with those. At no time would a
NeXT/Apple developer manually set these preprocessor defines, nor would the make
process. The tools allow a list, and the compiler is called repeatedly, each
time with the preprocessor values set appropriately.

If these values differ from the ones that libFLAC is already using (and they
almost surely are spelled differently, or have more or fewer underscores), then
perhaps a macOS section in a common header (like config.h) would be needed to
read the Apple-supplied preprocessor values and then set the corresponding
"FLAC" compatible values. Even if this works, it would probably
require defeating any Make logic that hard-codes those values (otherwise the
build would still be stuck with one architecture).

I recall that `configure` has long supported NeXT and Mac OS X, but I do not
recall whether anyone has shipped an open-source product that can build
multi-architecture. Hopefully, someone has done this, somewhere, and their setup
could be used as an example.

It's possible that I've always punted, built for each architecture
separately, and then manually combined the architectures into a single segmented
loader file (whatever the official name for that is, and the format has changed
since NeXT, of course). I hope it's not still like that. ;-)

Brian


On Sep 18, 2022, at 4:19 PM, Martijn van Beurden <mvanb1 at gmail.com>
wrote:
> 
> Op zo 18 sep. 2022 om 16:06 schreef brianw <brianw at
audiobanshee.com>:
>> When you refer to "runtime variables," do you really mean
build time?
> 
> Yes, build time. That was formulated wrong. 
> 
>> I would assume that the source code does not need to change in order to
support multiple architectures on macOS, but the compiler and/or make options
may need to change.
> 
> What I mean by changing code is mostly changing preprocessor defines.
Certain code is included or excluded from compilation by the preprocessor based
on defines that use variables set or unset by the configure or CMake
configuration. However, if these decisions need to be made at build time instead
of at configuration time for MacOS, these preprocessor defines needs to change,
hence the source code needs to change.
> 
> It might be possible to not touch the code by solving this in config.h for
CMake. In CMake config.h one can add conditional statements. I'm unsure
whether that is also possible for configure.
> 
> One could choose to support universal building only through CMake, as this
seems to easier to solve.
>  
>> I have not dug into the details yet. If someone does not find a
solution before I get back from vacation, I'll take a look. Usually, Xcode
makes this easy, and Xcode even produces a Makefile that works outside of the
GUI Xcode.app (i.e. it supports command-line building), so that might be a
reasonably quick option. However, I admit that keeping Xcode files up to date -
like any other GUI build environment - might not be worth the effort, but at
least the Makefile could be useful.
> 
> It could be such a Makefile provides clues on how and where to change the
build system as it is, yes.