RFC: setup.exe, mingw-libgpg-error/mingw-gcrypt

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Sun Mar 14 18:36:00 GMT 2010

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/.

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.


More information about the Cygwin-apps mailing list