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 <mva...@gmail.com> wrote: > > Op zo 18 sep. 2022 om 16:06 schreef brianw <bri...@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. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
