Questions about architecture detection

[longnguyen2004]

Why is the arch detection the way that it is, instead of relying on the already existing CMAKE_SYSTEM_PROCESSOR variable?

[mtl1979]

When cross-compiling, CMAKE_SYSTEM_PROCESSOR must be manually defined. It is currently also possible to target older, but compatible processor.

[nmoinvaz]

We could potentially use detect-arch.c for configure script too.

[mtl1979]

To use detect-arch.c we would also need to "port" detect-arch.cmake for bash which would not save any lines compared to the current test we have in configure.

[nmoinvaz]

Some of the logic from detect-arch.cmake could be put into detect-arch.c. It could print out both the arch and the base arch.

[nmoinvaz]

When cross-compiling, CMAKE_SYSTEM_PROCESSOR must be manually defined.

We don't do any cross-compiling scenarios without a toolchain file that defines CMAKE_SYSTEM_PROCESSOR. And even in the cross-compiling scenario, we don't actually run detect-arch.c but instead we do this:

zlib-ng/cmake/detect-arch.cmake

Lines 19 to 21 in a406284

	elseif(CMAKE_CROSSCOMPILING)
	set(ARCH ${CMAKE_C_COMPILER_TARGET})
	else()

It would seem to me that we don't need detect-arch.c and could just use CMAKE_SYSTEM_PROCESSOR.

[mtl1979]

@nmoinvaz We would still need to verify that contents of CMAKE_SYSTEM_PROCESSOR are normalized... At least for ARM, there is so many different processors and I'm not at all confident that we can gracefully handle all the values.

[nmoinvaz]

Yeah that seems to be the purpose of the detect-arch.cmake script - to normalize the values into ARCH and BASEARCH. It currently uses CMAKE_SYSTEM_PROCESSOR as a fallback.

CMAKE_SYSTEM_PROCESSOR is essentially the same value as uname -m which is used in configure. I'm not so sure there is much value in doing the compiler check when we already have CMAKE_SYSTEM_PROCESSOR.

[Dead2]

The value detect-arch.c brings is that it directly queries the compiler we are targeting and not whatever CMAKE thinks. It was made in response to having problems due to a mismatch between compiler and cmake. This solved that problem nearly completely (except for cross-compiling, however I guess it could perhaps even be used for that if providing only the correct CC?).

I have not investigated whether CMake is any better at this now than before, or whether this was a problem with bad cmake scripting, cmake distro problems or an inherent cmake problem.

That said, whatever the source of the problems were, I am not very eager to revert this unless there is a problem though, because that would be fixing something that actually works and it has a real possibility of regressions we are unable to test ahead of time.

[mtl1979]

Even though in most cases it is bad idea to "reinvent the wheel", when it comes to open-source software, sometimes getting the original software fixed is harder than rewriting the bad parts... I've worked with open-source software since December 1996 and rewritten a lot of code, some of which has been merged upstream. A lot of projects, including cmake, try to be backwards compatible as much as possible, but not always. Hardly any project however is forwards compatible. Can't really expect a program written for example 20 years old to run correctly on modern computers and operating systems.

We are trying hard to make things work with wide range of Windows and Linux versions, and if possible support some versions of MacOS and FreeBSD/OpenBSD/NetBSD. Any other operating systems might work, but there is no guarantee that all features work the same, especially the parts that depend on hardware detection.

We don't, or even can't, support every possible compiler version, be it old or new, as some compiler versions have serious bugs or breaking changes that are not present in any of the previous or subsequent major versions.