You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a case when a user wants to install headers into ${prefix}/include/GFTL (as opposed to dumping them into a common dir and promoting a chaos there). And then, inside GFTL there are V1 and V2 (without an unnecessary another include in between). There seems to be no trivial way to do that, and even patching CMake files requires multiple iterations, because settings in one CMakeLists file are ignored due to the same being redefined elsewhere.
If one does not notice what the build system does, everything gets coerced into ${prefix}/GFTL-${version}.
The text was updated successfully, but these errors were encountered:
I am a bit confused by this request. AFAIK, gFTL is installing in a canonical fashion. I am not strongly opposed to further generalization, but we have found that such changes often unintentionally break other build choices, and thus need to be thoroughly vetted.
Consider a case when a user wants to install headers into
${prefix}/include/GFTL
(as opposed to dumping them into a common dir and promoting a chaos there). And then, insideGFTL
there are V1 and V2 (without an unnecessary anotherinclude
in between). There seems to be no trivial way to do that, and even patching CMake files requires multiple iterations, because settings in one CMakeLists file are ignored due to the same being redefined elsewhere.If one does not notice what the build system does, everything gets coerced into
${prefix}/GFTL-${version}
.The text was updated successfully, but these errors were encountered: