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__ > (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
