Option to disable include arg modifications

[moloney]

Is your feature request related to a problem? Please describe.
I am building MRtrix3 with spack which builds all of the dependencies (e.g. Qt5) before hand, and then uses those custom built versions for includes / linking. Unfortunately the MRtrix3 "configure" script replaces all the -I <path> args with -idirafter <path> which breaks this.

Describe the solution you'd like
Would it be possible add some option to disable this behavior for users who are compiling against custom built dependencies? It might even make sense to make that the default?

Describe alternatives you've considered
I have a fix in spack that patches the configure script: spack/spack#41036

However I think this could bite anyone trying to use custom compiled dependencies.

[jdtournier]

Hi @moloney,

The use of -idirafter is fairly standard GCC, why does it cause problems with spack, exactly? There may be better solutions depending on the exact nature of the problem.

The reason we perform this substitution is to silence the warnings emitted from 3rd party packages like Qt, which pop up every so often (depending on the combination of compiler and/or the package), and can easily swamp the log file, making it very difficult for us to notice genuine warnings about our code from warnings emanating from 3rd party packages which we can't fix from our side and can safely ignore.

Both the -isystem and -idirafter options direct the compiler to treat headers in these locations as system headers, and to ignore warnings from these locations when compiling with -Wall. Currently, we substitute with -idirafter, which causes these locations to be listed after the standard system folders, whereas -isystem would causes these locations to be searched before the standard system folders (I'm not sure why we decided to use -idirafter rather than -isystem, but I remember there was some issue with -isystem, though I can't remember what - will have a dig around to job my memory).

If you substitute -idirafter with -isystem rather than -I and that fixes the problem, we'd be happy to merge that - assuming the reason for us using -idirafter is no longer current!

[jdtournier]

OK, relevant discussion around this in #1390. We used to use -isystem, but it caused problems on RHEL 7.5 when compiling a static build. That's a pretty niche case, and likely no longer a problem at all. I'd be happy to revert to -isystem now, in many ways that was always the correct flag. But that depends on whether that would fix the issue encountered here...

[moloney]

The issue is that we want our custom compiled version to come before any system version, and in my case spack is setting up the correct include precedence (using -I) but the MRTrix3 configure script overrides that. I understand using -idirafter is fairly standard, but I think going through and modifying the precedence of includes specified externally is not.

I think that modifying it to -isystem would not break things as the spack packages would still have precedence over system packages, and if that helps avoid some other issues as you mention then perhaps that is the best solution.

[jdtournier]

I'll freely admit that -idirafter was a hack to get around issues some of us faced at the time, and in hindsight I can see how it can cause trouble. I would also much rather be able to rely on the output of pkg-config directly, but the use of -I in some packages really can produce a mountain of warnings that we can do nothing about, so I'd rather stick to replacing them with -isystem.

If you can confirm that replace -idirafter with -isystem fixes the problem for you, I'd be happy to get that merged in.

[moloney]

I can confirm that using -isystem instead of -idirafter works for my use case. Thanks for the help!