[PATCH] Use automake (v5)
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
v2:
* Include tzmap.h in BUILT_SOURCES
* Make per-file flags appear after user-supplied CXXFLAGS, so they can
override optimization level.
* Correct .o files used to define symbols exported by libm.a
* Drop gcrt0.o mistakenly included in libgmon.a
* Add missing line continuations in GMON_FILES value
v3:
* use per-file flags for .c compilation
* override C{XX,}FLAGS, as they are set on the command line by top-level make
v4:
* Drop -Wno-error=write-strings from path_testsuite CXXFLAGS
v5:
* Update for changes in master
- Add -fno-threadsafe-statics to CXX flags
- Add hypotl.cc
- Remove fenv.cc (in favour of newlib), add fenv.c stub
- Add proc.5 manpage rules
---
winsup/Makefile.am | 19 +
winsup/Makefile.am.common | 15 +
winsup/Makefile.common | 51 --
winsup/autogen.sh | 1 +
winsup/configure.ac| 21 +-
winsup/cygserver/Makefile.am | 58 ++
winsup/cygwin/Makefile.am | 770 +
winsup/cygwin/config.h.in | 2 +-
winsup/doc/Makefile.am | 162 ++
winsup/testsuite/Makefile.am | 64 ++
winsup/testsuite/config/default.exp| 4 +-
winsup/testsuite/cygrun/Makefile.am| 21 +
winsup/testsuite/winsup.api/winsup.exp | 6 +-
winsup/utils/Makefile.am | 81 +++
winsup/utils/mingw/Makefile.am | 50 ++
15 files changed, 1266 insertions(+), 59 deletions(-)
create mode 100644 winsup/Makefile.am
create mode 100644 winsup/Makefile.am.common
delete mode 100644 winsup/Makefile.common
create mode 100644 winsup/cygserver/Makefile.am
create mode 100644 winsup/cygwin/Makefile.am
create mode 100644 winsup/doc/Makefile.am
create mode 100644 winsup/testsuite/Makefile.am
create mode 100644 winsup/testsuite/cygrun/Makefile.am
create mode 100644 winsup/utils/Makefile.am
create mode 100644 winsup/utils/mingw/Makefile.am
diff --git a/winsup/Makefile.am b/winsup/Makefile.am
new file mode 100644
index 0..067f74688
--- /dev/null
+++ b/winsup/Makefile.am
@@ -0,0 +1,19 @@
+# Makefile.am for winsup stuff
+#
+# This file is part of Cygwin.
+#
+# This software is a copyrighted work licensed under the terms of the
+# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
+# details.
+
+# This makefile requires GNU make.
+
+cygdocdir = $(datarootdir)/doc/Cygwin
+
+cygdoc_DATA = \
+ CYGWIN_LICENSE \
+ COPYING
+
+SUBDIRS = cygwin cygserver doc utils testsuite
+
+cygserver utils testsuite: cygwin
diff --git a/winsup/Makefile.am.common b/winsup/Makefile.am.common
new file mode 100644
index 0..884194df2
--- /dev/null
+++ b/winsup/Makefile.am.common
@@ -0,0 +1,15 @@
+# Makefile.am.common - common definitions for the winsup directory
+#
+# This file is part of Cygwin.
+#
+# This software is a copyrighted work licensed under the terms of the
+# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
+# details.
+
+flags_common=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe
-fbuiltin -fmessage-length=0
+
+# compiler flags commonly used (but not for MinGW compilation, because they
+# include the Cygwin header paths via @INCLUDES@)
+
+cxxflags_common=$(INCLUDES) -fno-rtti -fno-exceptions -fno-use-cxa-atexit
$(flags_common)
+cflags_common=$(INCLUDES) $(flags_common)
diff --git a/winsup/Makefile.common b/winsup/Makefile.common
deleted file mode 100644
index 3141bd111..0
--- a/winsup/Makefile.common
+++ /dev/null
@@ -1,51 +0,0 @@
-# Makefile.common - common definitions for the winsup directory
-#
-# This file is part of Cygwin.
-#
-# This software is a copyrighted work licensed under the terms of the
-# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
-# details.
-
-define justdir
-$(patsubst %/,%,$(dir $1))
-endef
-
-define libname
-$(realpath $(shell ${CC} --print-file-name=$1 $2))
-endef
-
-export PATH:=${winsup_srcdir}:${PATH}
-
-# Allow CFLAGS=-O,-g to control CXXFLAGS too
-opt=$(filter -O%,${CFLAGS}) $(filter -g%,${CFLAGS})
-override CXXFLAGS:=${filter-out -g%,$(filter-out -O%,${CXXFLAGS})} ${opt}
-
-cflags_common:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe
-fbuiltin -fmessage-length=0
-COMPILE.cc=${CXX} ${INCLUDES} ${CXXFLAGS} -fno-rtti -fno-exceptions
-fno-use-cxa-atexit ${cflags_common}
-COMPILE.c=${CC} ${INCLUDES} ${CFLAGS} ${cflags_common}
-
-top_srcdir:=$(call justdir,${winsup_srcdir})
-top_builddir:=$(call justdir,${target_builddir})
-
-cygwin_build:=${target_builddir}/winsup/cygwin
-newlib_build:=${target_builddir}/newlib
-
-VPATH:=${srcdir}
-
-.SUFFIXES:
-.SUFFIXES: .c .cc .def .S .a .o .d .s .E
-
-%.o: %.cc
- $(strip ${COMPILE.cc} -c -o $@ $<)
-
-%.o: %.c
- $(strip ${COMPILE.c} -c -o $@ $<)
-
-%.E: %.cc
- $(strip ${COMPILE.cc} -E -dD -o $@ $<)
-
-%.E: %.c
- $(strip ${COMPILE.c} -E
Re: [PATCH] Use automake (v5)
On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. Sorry about getting distracted from this. To summarize what I believe were the outstanding issues with v3 [1]: [1] https://cygwin.com/pipermail/cygwin-patches/2020q4/010827.html * 'INCLUDES' is the old name for 'AM_CPPFLAGS' warning from autogen.sh I plan to clean this up in a future patch * 'ps$(EXEEXT)' previously defined' warning from autogen.sh It seems to be a shortcoming of automake that there's no way to suppress just that warning. One possible solution is build ps.exe with a different name and rename it while installing, but I think that is counter-productive (in the sense that it trades this warning for making the build more complex to understand) * some object files are in a unexpected places in the build file hierarchy (compared to naive expectations and/or the non-automake build) I'm not sure if this is merely an aesthetic issue, or if there are problems this causes.
Re: [PATCH] Use automake (v5)
On Apr 20 21:15, Jon Turney wrote: > On 20/04/2021 21:13, Jon Turney wrote: > > For ease of reviewing, this patch doesn't contain changes to generated > > files which would be made by running ./autogen.sh. > > Sorry about getting distracted from this. To summarize what I believe were > the outstanding issues with v3 [1]: > > [1] https://cygwin.com/pipermail/cygwin-patches/2020q4/010827.html > > * 'INCLUDES' is the old name for 'AM_CPPFLAGS' warning from autogen.sh > > I plan to clean this up in a future patch > > * 'ps$(EXEEXT)' previously defined' warning from autogen.sh > > It seems to be a shortcoming of automake that there's no way to suppress > just that warning. > > One possible solution is build ps.exe with a different name and rename it > while installing, but I think that is counter-productive (in the sense that > it trades this warning for making the build more complex to understand) > > * some object files are in a unexpected places in the build file hierarchy > (compared to naive expectations and/or the non-automake build) This is the only minor qualm I have with this patch. It would be nice to have the mingw sources and .o files in the mingw subdir. It would simply be a bit cleaner. The files shared between cygwin and mingw (that's only path.cc, I think) could be handled by an include, i. e. utils/ path.cc (full implementation) utils/mingw/ path.cc: #include "../path.cc" However, this isn't a showstopper, feel free to push what you're comfortable with. Still, wWhat do you think? Any problem to move the mingw stuff to the mingw subdir entirely? Thanks, Corinna
Re: [PATCH] Use automake (v5)
On Apr 21 18:40, Corinna Vinschen wrote: > On Apr 20 21:15, Jon Turney wrote: > > On 20/04/2021 21:13, Jon Turney wrote: > > > For ease of reviewing, this patch doesn't contain changes to generated > > > files which would be made by running ./autogen.sh. > > > > Sorry about getting distracted from this. To summarize what I believe were > > the outstanding issues with v3 [1]: > > > > [1] https://cygwin.com/pipermail/cygwin-patches/2020q4/010827.html > > > > * 'INCLUDES' is the old name for 'AM_CPPFLAGS' warning from autogen.sh > > > > I plan to clean this up in a future patch > > > > * 'ps$(EXEEXT)' previously defined' warning from autogen.sh > > > > It seems to be a shortcoming of automake that there's no way to suppress > > just that warning. > > > > One possible solution is build ps.exe with a different name and rename it > > while installing, but I think that is counter-productive (in the sense that > > it trades this warning for making the build more complex to understand) > > > > * some object files are in a unexpected places in the build file hierarchy > > (compared to naive expectations and/or the non-automake build) > > This is the only minor qualm I have with this patch. It would be nice > to have the mingw sources and .o files in the mingw subdir. It would > simply be a bit cleaner. The files shared between cygwin and mingw > (that's only path.cc, I think) could be handled by an include, i. e. > > utils/ > > path.cc (full implementation) > > utils/mingw/ > > path.cc: > > #include "../path.cc" I wonder if it wouldn't make sense to split out the mingw-only parts of path.cc entirely. I had a quick view into the file and it turns out that of the almost 1000 lines in this file, only about 100 lines are used by mount. All the rest is only used by mingw code, i. e., cygcheck and strace. That's obviously not part of this patch, but something we should keep in mind for a later cleanup. Corinna
Re: [PATCH] Use automake (v5)
On Apr 22 13:57, Corinna Vinschen wrote:
> On Apr 21 18:40, Corinna Vinschen wrote:
> > On Apr 20 21:15, Jon Turney wrote:
> > > On 20/04/2021 21:13, Jon Turney wrote:
> > > > For ease of reviewing, this patch doesn't contain changes to generated
> > > > files which would be made by running ./autogen.sh.
> > >
> > > Sorry about getting distracted from this. To summarize what I believe
> > > were
> > > the outstanding issues with v3 [1]:
> > >
> > > [1] https://cygwin.com/pipermail/cygwin-patches/2020q4/010827.html
> > >
> > > * 'INCLUDES' is the old name for 'AM_CPPFLAGS' warning from autogen.sh
> > >
> > > I plan to clean this up in a future patch
> > >
> > > * 'ps$(EXEEXT)' previously defined' warning from autogen.sh
> > >
> > > It seems to be a shortcoming of automake that there's no way to suppress
> > > just that warning.
> > >
> > > One possible solution is build ps.exe with a different name and rename it
> > > while installing, but I think that is counter-productive (in the sense
> > > that
> > > it trades this warning for making the build more complex to understand)
> > >
> > > * some object files are in a unexpected places in the build file hierarchy
> > > (compared to naive expectations and/or the non-automake build)
> >
> > This is the only minor qualm I have with this patch. It would be nice
> > to have the mingw sources and .o files in the mingw subdir. It would
> > simply be a bit cleaner. The files shared between cygwin and mingw
> > (that's only path.cc, I think) could be handled by an include, i. e.
> >
> > utils/
> >
> > path.cc (full implementation)
> >
> > utils/mingw/
> >
> > path.cc:
> >
> > #include "../path.cc"
>
> I wonder if it wouldn't make sense to split out the mingw-only parts
> of path.cc entirely. I had a quick view into the file and it turns
> out that of the almost 1000 lines in this file, only about 100 lines
> are used by mount. All the rest is only used by mingw code, i. e.,
> cygcheck and strace.
>
> That's obviously not part of this patch, but something we should keep
> in mind for a later cleanup.
I tried this as a POC and it's not much of a problem. See the below
patch. Cleaning up the includes is still to do.
Corinna
diff --git a/winsup/utils/Makefile.in b/winsup/utils/Makefile.in
index e4f55dd3c50e..a2d8c426fdac 100644
--- a/winsup/utils/Makefile.in
+++ b/winsup/utils/Makefile.in
@@ -58,10 +58,10 @@ endif
# List all objects to be compiled in MinGW mode. Any object not on this
# list will will be compiled in Cygwin mode implicitly, so there is no
# need for a CYGWIN_OBJS.
-MINGW_OBJS := bloda.o cygcheck.o cygwin-console-helper.o dump_setup.o ldh.o
path.o strace.o
+MINGW_OBJS := bloda.o cygcheck.o cygwin-console-helper.o dump_setup.o ldh.o
mingw-path.o strace.o
MINGW_LDFLAGS:=-static
-CYGCHECK_OBJS:=cygcheck.o bloda.o path.o dump_setup.o
+CYGCHECK_OBJS:=cygcheck.o bloda.o mingw-path.o dump_setup.o
ZLIB:=-lz
.PHONY: all
@@ -69,12 +69,10 @@ all:
# If a binary should link in any objects besides the .o with the same
# name as the binary, then list those here.
-strace.exe: path.o
-cygcheck.exe: cygcheck.o bloda.o path.o dump_setup.o
+strace.exe: mingw-path.o
+cygcheck.exe: cygcheck.o bloda.o mingw-path.o dump_setup.o
-path-mount.o: path.cc
- ${COMPILE.cc} -c -DFSTAB_ONLY -o $@ $<
-mount.exe: path-mount.o
+mount.exe: path.o
.PHONY: tzmap
tzmap:
diff --git a/winsup/utils/mingw-path.cc b/winsup/utils/mingw-path.cc
new file mode 100644
index ..6c60a8eb9bae
--- /dev/null
+++ b/winsup/utils/mingw-path.cc
@@ -0,0 +1,795 @@
+/* path.cc
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license. Please consult the file "CYGWIN_LICENSE" for
+details. */
+
+/* The purpose of this file is to hide all the details about accessing
+ Cygwin's mount table, shortcuts, etc. If the format or location of
+ the mount table, or the shortcut format changes, this is the file to
+ change to match it. */
+
+#include "path.cc"
+
+/* Used when treating / and \ as equivalent. */
+#define isslash(ch) \
+ ({ \
+ char __c = (ch); \
+ ((__c) == '/' || (__c) == '\\'); \
+ })
+
+
+static const GUID GUID_shortcut =
+ {0x00021401L, 0, 0, {0xc0, 0, 0, 0, 0, 0, 0, 0x46}};
+
+enum {
+ WSH_FLAG_IDLIST = 0x01, /* Contains an ITEMIDLIST. */
+ WSH_FLAG_FILE = 0x02,/* Contains a file locator element. */
+ WSH_FLAG_DESC = 0x04,/* Contains a description. */
+ WSH_FLAG_RELPATH = 0x08, /* Contains a relative path. */
+ WSH_FLAG_WD = 0x10, /* Contains a working dir. */
+ WSH_FLAG_CMDLINE = 0x20, /* Contains command line args. */
+ WSH_FLAG_ICON = 0x40 /* Contains a custom icon. */
+};
+
+struct win_shortcut_hdr
+ {
+DWORD size;/* Header size in bytes. Must contain 0x4c. */
+GUID magic;/* GUID of shortcut files. */
+DWORD flags; /* Co
Re: [PATCH] Use automake (v5)
On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again.
Re: [PATCH] Use automake (v5)
On 26/04/2021 16:03, Corinna Vinschen wrote: On Apr 22 13:57, Corinna Vinschen wrote: On Apr 21 18:40, Corinna Vinschen wrote: On Apr 20 21:15, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: * some object files are in a unexpected places in the build file hierarchy (compared to naive expectations and/or the non-automake build) This is the only minor qualm I have with this patch. It would be nice to have the mingw sources and .o files in the mingw subdir. It would simply be a bit cleaner. The files shared between cygwin and mingw (that's only path.cc, I think) could be handled by an include, i. e. utils/ path.cc (full implementation) utils/mingw/ path.cc: #include "../path.cc" I wonder if it wouldn't make sense to split out the mingw-only parts of path.cc entirely. I had a quick view into the file and it turns out that of the almost 1000 lines in this file, only about 100 lines are used by mount. All the rest is only used by mingw code, i. e., cygcheck and strace. That's obviously not part of this patch, but something we should keep in mind for a later cleanup. I tried this as a POC and it's not much of a problem. See the below patch. Cleaning up the includes is still to do. Thanks, this seems workable. I'll take a look.
Re: [PATCH] Use automake (v5)
On 4/27/2021 11:50 AM, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again. I'm confused about how the generated files are going to get regenerated when necessary. I see calls to autogen (which I guess is /usr/bin/autogen.exe from the autogen package) in the Makefiles, but I don't see any calls to autogen.sh. Is the latter no longer needed? Ken
Re: [PATCH] Use automake (v5)
On 4/27/2021 12:52 PM, Ken Brown wrote: On 4/27/2021 11:50 AM, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. I pushed this patch. If you have an existing build directory, while you might get away with invoking 'make' at the top-level, I would recommend blowing it away and configuring again. I'm confused about how the generated files are going to get regenerated when necessary. I see calls to autogen (which I guess is /usr/bin/autogen.exe from the autogen package) in the Makefiles, but I don't see any calls to autogen.sh. Is the latter no longer needed? Oh, never mind. The Makefiles just call autoconf, etc., as needed. Ken
Re: [PATCH] Use automake (v5)
On 27/04/2021 18:00, Ken Brown wrote:
On 4/27/2021 12:52 PM, Ken Brown wrote:
On 4/27/2021 11:50 AM, Jon Turney wrote:
On 20/04/2021 21:13, Jon Turney wrote:
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
I pushed this patch.
If you have an existing build directory, while you might get away
with invoking 'make' at the top-level, I would recommend blowing it
away and configuring again.
I'm confused about how the generated files are going to get
regenerated when necessary. I see calls to autogen (which I guess is
/usr/bin/autogen.exe from the autogen package) in the Makefiles, but I
That's some cygnus top-level weirdness I don't understand.
don't see any calls to autogen.sh. Is the latter no longer needed?
There is (still) an autogen.sh in winsup/ ...
Oh, never mind. The Makefiles just call autoconf, etc., as needed.
... but you should now never need to explicitly use it, as
('maintainer-mode') rules now exist in the Makefile to do what's needed.
If you do need to make changes in the autofoolery which are going to be
pushed, then specific versions of the autotools still need to be used
(to avoid these generated files thrashing between forms generated by
different versions)
Re: [PATCH] Use automake (v5)
On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. Some possible items of future work I noted: * Documentation is now always built (rather than dangerously ignoring any errors) Although this is half-arsed at the moment, as we don't require the documentation tools at configure time, we'll just fail when the rules are executed if they are missing. Perhaps there should be explicit configuration to build documentation or not? * Use AM_V_GEN to silence (most?) custom rules * -Wimplicit-fallthrough, -Werror could (should?) be set in top-level Makefile.am.common, rather than individual subdirs * Some custom rules have multiple outputs and workarounds to ensure the rule only runs once Ideally these would be re-written using make 4.3 'grouped targets', but perhaps not yet... * Some custom rules could be simplified e.g. mkvers.sh generates version.cc and winver.rc, then runs windres on windver.rc * 'make our include directories absolute so we don't have to worry about making them relative to the subdirectory we happen to be building in' is sufficiently obscure that it at least deserves a comment. * Rather than a huge list of --replace options to mkimport inline in the Makefile, it might be more sensible to augment that tool the read a list of replacement names from a file, and put them there.
Re: [PATCH] Use automake (v5)
On 2021-05-02 09:28, Jon Turney wrote: Some possible items of future work I noted: * -Wimplicit-fallthrough, -Werror could (should?) be set in top-level Makefile.am.common, rather than individual subdirs Perhaps keep -Werror for Cygwin sources only where we can directly deal with new warnings generated due to prompt gcc releases with improvements under Cygwin (thanks to Achim and JonY). With other distros' gcc releases lagging, package builds are getting more warnings during cygport builds, which would have to be dealt with either by more Cygwin patches and/or working with upstream, by toggling off -Werror, or specific -Wno-... options which could result in suppressing useful output, as well as delaying package releases. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Re: [PATCH] Use automake (v5)
On May 2 12:25, Brian Inglis wrote: > On 2021-05-02 09:28, Jon Turney wrote: > > Some possible items of future work I noted: > > > * -Wimplicit-fallthrough, -Werror could (should?) be set in top-level > > Makefile.am.common, rather than individual subdirs Careful, the implicit-fallthrough values are different. Not saying they *have* to be different, but that certainly requires code changes. > Perhaps keep -Werror for Cygwin sources only where we can directly deal with > new warnings generated due to prompt gcc releases with improvements under > Cygwin (thanks to Achim and JonY). No, -Werror should be used for all source dirs under winsup. > With other distros' gcc releases lagging, package builds are getting more > warnings during cygport builds, which would have to be dealt with either by > more Cygwin patches and/or working with upstream, by toggling off -Werror, > or specific -Wno-... options which could result in suppressing useful > output, as well as delaying package releases. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.]
Re: [PATCH] Use automake (v5)
On May 2 16:28, Jon Turney wrote: > On 20/04/2021 21:13, Jon Turney wrote: > > For ease of reviewing, this patch doesn't contain changes to generated > > files which would be made by running ./autogen.sh. > > Some possible items of future work I noted: > > * Documentation is now always built (rather than dangerously ignoring any > errors) > > Although this is half-arsed at the moment, as we don't require the > documentation tools at configure time, we'll just fail when the rules are > executed if they are missing. > > Perhaps there should be explicit configuration to build documentation or > not? `make doc'? It wouldn't be tricky to add that to the cygwin.cygport file... > * Use AM_V_GEN to silence (most?) custom rules > > * -Wimplicit-fallthrough, -Werror could (should?) be set in top-level > Makefile.am.common, rather than individual subdirs See my other mail. > * Some custom rules have multiple outputs and workarounds to ensure the rule > only runs once > > Ideally these would be re-written using make 4.3 'grouped targets', but > perhaps not yet... > > * Some custom rules could be simplified > > e.g. mkvers.sh generates version.cc and winver.rc, then runs windres on > windver.rc > > * 'make our include directories absolute so we don't have to worry about > making them relative to the subdirectory we happen to be building in' is > sufficiently obscure that it at least deserves a comment. I'm not sure I understand... -v, please? > * Rather than a huge list of --replace options to mkimport inline in the > Makefile, it might be more sensible to augment that tool the read a list of > replacement names from a file, and put them there. Ack Thanks, Corinna
Re: [PATCH] Use automake (v5)
On 03/05/2021 11:43, Corinna Vinschen wrote: On May 2 16:28, Jon Turney wrote: On 20/04/2021 21:13, Jon Turney wrote: For ease of reviewing, this patch doesn't contain changes to generated files which would be made by running ./autogen.sh. Some possible items of future work I noted: * Documentation is now always built (rather than dangerously ignoring any errors) Although this is half-arsed at the moment, as we don't require the documentation tools at configure time, we'll just fail when the rules are executed if they are missing. Perhaps there should be explicit configuration to build documentation or not? `make doc'? Yeah, that's probably the right thing to do. [...] * 'make our include directories absolute so we don't have to worry about making them relative to the subdirectory we happen to be building in' is sufficiently obscure that it at least deserves a comment. I'm not sure I understand... -v, please? Yeah, that's why it needs comment :) realdirpath() in winsup/configure.ac makes paths absolute (and canonical) Therefore we can use things set with it (AC_CYGWIN_INCLUDES, target_builddir, winsup_srcdir) in Makefile.am in arbitrarily deep subdirectories, and things just happen to work (which wouldn't be the case if they contained relative paths) It's all a hangover from when it used to be even more complex (see commit 39e8d907), and looking at this again, this could probably be cleaned-up some more (perhaps using $top_builddir, $top_srcdir?).
