On Sun, Mar 14, 2010 at 02:00:51PM -0400, Charles Wilson wrote: >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?
This has always bugged me too. I've looked at the machinery which seems to insist on repeated recompilation of libg* objects but I've never been motivated enough to fix it. Moving it out of the tree entirely would be a nicer fix. So +1 from me. cgf
