lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Using -isystem and dependencies generation


From: Vadim Zeitlin
Subject: [lmi] Using -isystem and dependencies generation
Date: Wed, 7 Oct 2020 01:29:15 +0200

 Hello,

 I've just found a problem due to using -isystem for many of the headers
used by lmi in workhorse.make and -MMD in MAKEDEPEND_FLAGS in
autodependency.make. This compiler switch explicitly excludes the system
headers from the dependencies output and this is problematic because in our
case these headers may change, e.g. due to updating a submodule containing
xmlwrapp headers, to give a completely random example, but the files using
them won't be rebuilt.

 I don't like using -isystem for something which isn't actually a system
header much, but I believe you absolutely want to use it rather than deal
with the warnings in third party headers. If this is indeed the case (even
though working around such problems should be much simpler once all third
party headers are in submodules, i.e. under our control), then I believe we
really should use -MD rather than -MMD to avoid such rebuild problems. Do
you agree with this and, if so, should I make a patch doing it (or,
considering that it's a single character change, just make this commit
directly) or will you just change it yourself?

 Also, less importantly, but looking at autodependency.make I see that it
uses both -MMD and -MF which seems redundant, as -MMD (or -MD) already does
exactly the same thing as this -MF option does, quoting gcc(1):

        -MD is equivalent to -M -MF file, except that -E is not implied.
        The driver determines file based on whether an -o option is given.
        If it is, the driver uses its argument but with a suffix of .d,
        otherwise it takes the name of the input file, removes any
        directory components and suffix, and applies a .d suffix.

 So in addition to the single character change above, I'd also remove -MF.

 Please let me know what do you think about this, thanks in advance,
VZ

Attachment: pgp51cvIA_1fY.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]