Re: [PATCH 3/3] Remove recursive configure for cygwin

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Oct 23 11:27, Corinna Vinschen wrote:
> 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.
> 
> Ok
> 
> > > > 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__

Oh, btw., this is bothering me for a while now.  This may have been
a nice idea at the time, but wouldn't it be much better to put
common methods into headers and otherwise split the source between
client and server code?


Corinna



> > (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.
> 
> 
> Corinna