[PATCH 3/3] Remove recursive configure for cygwin

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Oct 23 09:27:00 GMT 2020

On Oct 22 19:57, Jon Turney wrote:
> On 22/10/2020 18:27, Corinna Vinschen wrote:
> > On Oct 21 20:47, Jon Turney wrote:
> > > There's doesn't seem to be much use in independently building these
> > > subdirectories,
> > 
> > Uhm... that doesn't match how I'm working in these dirs.  I'm building
> > the subdirs independently all the time, especially during debugging
> > sessions.  I'd not want to lose the ability to build in the
> > cygwin or utils dirs independently.
> Sorry for being unclear here.  What I mean here is we are currently handling
> those subdirectories as if they are independent packages, which could
> distributed and built separately.
> (See discussion of AC_CONFIG_SUBDIRS in [1])
> [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Subdirectories.html
> This doesn't remove the ability to run make in those subdirectories.


> > > so allowing them to be independently configured seems
> > > pointless and overcomplicated.
> > 
> > There's not much of a reason to allow independent configuring, I guess,
> > but apart from the base configure run during a build from top-level,
> > I sometimes run configure only in the dir I change or add files.
> I actually skimped on writing the rules which reconfigure when needed when
> make is run in a subdirectory, as working them out seemed complex and a bit
> redundant, as when I convert to automake, it writes them for you.
> I guess I should take another look at that.
> > > The order in which the subdirectories are built is still a little odd,
> > > as cygwin is linked with libcygserver, and cygserver is then linked with
> > > cygwin. So, we build the cygwin directory first, which invokes a build
> > > of libcygserver in the cygserver directory, and then build in the
> > > cygserver directory to build the cygserver executable.
> > 
> > Does creating a new subdir called libcygserver just to build the lib
> > clean up things, perhaps?
> I did experiment with something like that, but I'm not sure if it makes
> things any clearer, as:
> (i) It's the same source files built with/without -D__OUTSIDE_CYGWIN__
> (ii) building libcygserver requires the generated file globals.h

I don't actually see a reason to keep this.

There's nothing wrong simplifying this stuff, removing mkglobals_h and
creating a static version of globals.h inside the source dir.  For
instance, defining enum exit_states or enum winsym_t in global.cc just
to generate a globals.h from there is kind of weird anyway.  Getting rid
of another undocumented perl script and getting rid of the globals.h
build rule sounds rather good to me.


More information about the Cygwin-patches mailing list