On Tue, 10 Oct 2023 at 12:17, Ian McInerney via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> >> Hey all, >> >> Recently, one of the folks working on packaging stuff in Fedora KDE >> nearly missed an issue caused by GCC emitting a warning about missing >> include dirs: >> >> > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory [-Wmissing-include-dirs] >> > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or directory [-Wmissing-include-dirs] >> >> I did manage to figure out this meant we needed an additional build >> dependency (qt6-qtbase-private-devel, FYI), but it made me think if >> there's a reason this shouldn't be an error. >> >> If it's an error, then at least we can evaluate these things and >> ensure we have the right build inputs... > > > Missing an include directory isn't necessarily the problem though, it is the missing headers that aren't present when they are included that would be - and that should trigger a build error for the missing file. What advantage does failing on this warning provide that the failure on the include file missing doesn't? Typically, yes, I'd expect a failure. But it's possible for code to do: #if __has_include(<foo.h>) # include <foo.h> // use features in that header #else // roll your own inferior version #endif And so the code could compile either way, but with results that differ depending on whether <foo.h> is found or not. The extra -I include dir could be given to the compiler so that if <foo.h> is present in that dir, it will be found and used. If it's not present, there's no harm. I don't expect this to be a very widely used pattern though. The above doesn't necessarily argue for or against making it an error. There are arguments either way. Making it an error might give some maintainers a heads up that something's missing, but for other packages it would break a valid use case. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
