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
