subdirs for headers in header_symlinks

[RonRahaman]

Hi all,

I'm using MOOSE to with an external app and the header includes are getting all fouled up.

My problem (I think) is that, when the MOOSE build system creates header_symlinks, it flattens the subdirectories for my external app's headers. For example, my external app has headers like fmt/locale.h and openmc/nuclide.h, but MOOSE just generates header_symlinks/locale.h and header_symlinks/nuclide.h.

This is a big problem for locale.h, in particular, since, when the build line adds header_symlinks as an include path, then header_symlinks/locale.h interferes with the C++ library's locale.h. This wouldn't be a problem if the subdirectory structure was retained in header_symlinks. For example, if MOOSE generated header_symlinks/fmt/locale.h, then I think things would be fine.

Is there a way to hack MOOSE so that I get the subdirectory structure in header_symlinks?

[RonRahaman]

@aprilnovak

[aeslaughter]

@permcody @friedmud Can you take a look at this question, you probably know what to without digging around.

[friedmud]

Had a meeting with @RonRahaman and @aprilnovak ... we talked about what's happening, and how to mitigate it. Here is the breakdown:

• They were dumping .h files into the include directory of their app by doing make install of another code to their app directory. Resolution: don't do that 😛
• It was happening intermittently because their makefile was missing dependencies that was causing non-determinism in order of the build of their app and that other code.
• As a temporary fix they can set MOOSE_HEADER_SYMLINKS=false in their environment to turn off header symlinking

@RonRahaman let me know if I missed something on this

[RonRahaman]

Yep, that's about it. I've updated my build so our third-party apps don't put headers in include/, and it works fine now.

[RonRahaman]

Thanks for your help!