One of the things that bugs me about building setup.exe is if you do a make from the top level, it always recurses into the libgpg-error and libgcrypt subdirectories, even when there's nothing to do. Because part of our build process 'installs' the gcrypt stuff into a local private 'installation' directory, this is /not/ actually a fast no-op; it takes a reasonable amount of time, each time. So, you end up 'installing' libgpg over and over and over -- unless you retrain your fingers to do 'make setup.exe' rather than simply 'make'.
Plus, why exactly do we include such a large package within setup's source repo -- it's a sort of departure from the mechanism we use for the compression libraries. So...I propose to create mingw-libgpg-error(-devel) and mingw-gcrypt(-devel) packages, and then rework setup's build process to use those external (static) libraries instead. But I don't want to waste my time if there are good reasons for the way we do it now, and I'll ultimately run into a roadblock getting those ITPs accepted and patches merged. The only real distinction I see is that at present, you never get any of the gcrypt headers or libs installed anywhere publicly visible; my way, they'd obviously go into /usr/include/mingw/ and /usr/lib/mingw/. So...RFC? -- Chuck
