This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: RFC: setup.exe, mingw-libgpg-error/mingw-gcrypt
On 14/03/2010 18:35, Christopher Faylor wrote:
> 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'.
> This has always bugged me too.
I don't remember what the motivation was for doing the pseudo-install step
in the first place, it was something you added after my initial version of the
code. Possibly it was to do with not wanting to embed knowledge of the
libraries' build tree into setup's makefile.
> 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.
Well, we could do this:
Index: Makefile.am
===================================================================
RCS file: /cvs/cygwin-apps/setup/Makefile.am,v
retrieving revision 2.77
diff -p -u -r2.77 Makefile.am
--- Makefile.am 28 Jun 2009 03:50:42 -0000 2.77
+++ Makefile.am 14 Mar 2010 20:29:05 -0000
@@ -321,4 +321,4 @@ snapshot: release
.PHONY: ${INST_SUBDIRS}
${INST_SUBDIRS}:
- ${MAKE} -C $@ install
+ ${MAKE} -C $@ -q || ${MAKE} -C $@ install
... which only does the install if there would be anything to do during the
'all' part of the build, but that isn't robust against deleting all or part of
the $objdir/inst tree. It does speed up the build very nicely though! We
could even add just a few extra static dependencies that would re-run the
install stage(s) if the needed lib(s) wasn't found in the inst/ tree. (Or we
could even go back to linking the build libs directly out of the sub-$objdirs.)
> Moving it out of the tree entirely would be a nicer fix.
Sounds good too. I checked the whole lot in in the first place because we
were in a rush to get it done, and because the thought of making it into
separate packages for the distro didn't occur to me at the time. There's
certainly no special reason for it.
cheers,
DaveK