On Mon, 7 Aug 2017, Martin Storsjö wrote:

On Sun, 6 Aug 2017, JonY via Mingw-w64-public wrote:

On 08/06/2017 02:59 PM, David Grayson wrote:
I would agree with Martin; I think it's a very good practice for
source files to have an error or not define a function instead of
defining a function that can't possibly work and letting the build
proceed with a broken function.  Compiler and linker errors are much
easier to figure out than segmentation faults.

If you try to do it with autoconf, it's easy for the autoconf layer to
get out of sync with the rest of the source code, or for someone to
decide they want to use their own build system instead of the autoconf
layer.  And it won't help very much when porting to a new architecture
like Martin said.


The source file could be better split so you don't need to read all of
it, and you don't need any preprocessor directives sprinkled about, eg
math/asm/arm, math/common, math/asm/x86.

Sure, that'd at least make things clearer. It's straightforward to do for the plain assembly files, a bit less so for the C files that consist of mostly inline assembly, or C files with templates with inline assembly. But I guess I could start with the plain assembly files.

Does the 4 patch set I just sent look sensible and like what you had in mind? It doesn't sort out all files, but at least the ones that aren't built in all architectures, and all .S files.

I'll refrain from rebasing the arm64 patchset on top of this until it's settled and merged.

// Martin
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Mingw-w64-public mailing list

Reply via email to