On Fri, 2018 Jun 22 16:44+0100, ph10@??? wrote:
> >
> > That won't be a problem, because an -I$(builddir)/src would be part
> > of the #includes. (Note that #include<> typically searches the list
> > of -I directories before looking in the system directories.)
>
> ... but we'd need "always" rather than "typically" wouldn't we. :-)
I say "typically" because I know of at least two cases where it isn't
necessarily true: The IBM XLC compiler on z/OS (mainframe system), and
an in-house C compiler used by my employer (long story). Neither follow
standard Unix #include behavior by default due to strange historical
reasons. But even then, both can be coerced into following the norm with
an appropriate option.
So I can't say "always," but the counterexamples are unlikely to be
an issue ;)
> CMake (on my Linux box) puts pcre2.h and config.h into the build
> directory directly, not into builddir/src. However, Autoconf does put
> them into buildir/src.
The inconsistency irks me, but not enough to do something about it.
Typically, the generated file should go into the same subdirectory (in
the build tree) as the .in file template. (And config.h[.in] usually
lives in the top-level directory.)
> BUT ... running "make -n" with CMake does show the commands with
> appropriate -I settings, so it does seem to do the right thing.
Yes, but that's on Linux/Unix. Here is a compiler invocation from a
Windows build using an NMAKE makefile:
[ 3%] Building C object CMakeFiles/pcre2-8.dir/src/pcre2_auto_possess.c.obj
C:\PROGRA~2\MICROS~1\VC\bin\amd64\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 -IE:/tmp/pcre2-10.32-RC1/src /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -IE:\tmp\pcre-build -IE:\tmp\pcre2-10.32-RC1 -IE:\thirdpty\arch\win64\include -DHAVE_CONFIG_H -DPCRE2_CODE_UNIT_WIDTH=8 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS /FoCMakeFiles\pcre2-8.dir\src\pcre2_auto_possess.c.obj /FdCMakeFiles\pcre2-8.dir\ -c E:\tmp\pcre2-10.32-RC1\src\pcre2_auto_possess.c
I do not know where that first -I directive is coming from. I've only
been able to determine that it has nothing to do with
INCLUDE_DIRECTORIES().
> > I've been building within the SVN tree, which has the file:
>
> I'm now wondering why it has the file? Perhaps some historical reason,
> but I see no reason why it should have it. It does, after all, have
> pcre2.h.generic which is identical. Perhaps I should remove pcre2.h
> from the SVN repo.
>
> > Removing it may solve the immediate issue, but the setup will remain
> > fragile to any errant file that is left under $(srcdir)/src/. I
> > think using <pcre.h> consistently, in addition to removing the file
> > from SVN, is the best solution.
>
> I *have* removed pcre2.h from the SVN repo.
Ah, this is good. Yes, that file was a source of trouble.
> You are right about read-only source directories; I had overlooked
> that. Unfortunately rm -f barfs at a read-only file, so I have
> reversed that patch.
Fixing the #includes is the right way to go anyway. Deleting files is an
unexpected behavior, as well.
> I'm still unhappy about changing "" to <> because it seems to go
> against the presumption that <> is for system headers and "" is for
> headers local to the program.
I fully understand your reasoning here, but this semantic arose with
"classic" in-source-tree builds. When you go to out-of-source builds, ""
no longer works correctly, because it breaks the rule of looking in the
build tree first (if used in a file in the source tree).
What I usually do to maintain the distinction between system vs. program
headers is I #include the latter in a "section" that is visibly separate
from the former.
--Daniel
P.S.: Please Cc: me on any replies, as I am not subscribed to this list.
--
Daniel Richard G. || skunk@???
My ASCII-art .sig got a bad case of Times New Roman.
