When you refer to "runtime variables," do you really mean build time? It's not really an option to wait until flac runs to determine the runtime architecture. I suspect you mean make variables that are used at build time. 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. 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. Brian Willoughby On Sep 17, 2022, at 5:45 PM, Martijn van Beurden <mvanb1 at gmail.com> wrote:> As is being discussed here: https://github.com/xiph/flac/issues/453 libFLAC has some issues building on MacOS. More specifically, building for aarch64 and x86_64 at the same time. > > The problem here is that autotools and CMake expect to configure for one architecture at a time. Also, code is dependent on that configuration, and not on runtime variables. > > It seems a challenge to me: we need both configuration and building to be aware of stuff being built in parallel for two architectures. Also, it is important not to break anything on other architectures, so we might need both approaches: relying on either run-time arch for MacOS and on static configuration for other systems. > > I do not have Apple hardware nor any experience with this. I can't seem to find much documentation on porting autotools or CMake scripts for Apple's universal builds. If there is anyone here up for this challenge, do not hesitate to let me know :)
Martijn van Beurden
2022-Sep-18 14:19 UTC
[flac-dev] 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>