Release 1.3.10 and then merge daemon code

Charles Wilson
Wed Feb 13 10:56:00 GMT 2002

Christopher Faylor wrote:

> Both of those makefiles are rather old so it would be hard to believe
> that something this basic is required.  The INSTALL_DATA script is
> supposed to create the directories automatically.  AFAICT, it is working
> correctly.  

Okay, whatever.  I'm just reporting my experience -- yes, 
$(INSTALL_DATA) [ == "$(SHELL) $(updir)/install-sh -c" ] *should* do 
this, but in certain cases it is not doing so on my system.

It has not been working properly for months, for me.  I've had to create 
a "template" tree of emtpy installation directories by hand before 
running 'make install' (I even have a script...)  Since nobody else 
seemed to complain, I figured it was just me -- but I finally got tired 
of it, and provided a patch.  If you don't want it, fine; but I'm 
keeping it in my local CVS archive because creating directories by hand 
(or script) is a drag.

Perhaps my work style is weird: I gather that most folks compile a new 
DLL and either (a) copy only the DLL into /usr/bin, or (b) do a complete 
direct install into /usr.  I tend to create "fake" 'cygwin', 'mingw', 
and 'w32api' packages and then use setup to install the new packages. 
This requires doing a 'make install' into an empty temp dir, and running 
a build script to "package" the result.

Note that in either the (a) or (b) scenario, the problem of 
non-pre-existing installation directories never comes up. My guess is 
that ONLY you, me, and Earnie *ever* do anything like "my" procedure. 
You because you're the cygwin package king, Earnie because he maintains 
the mingw and w32api packages, and me because I'm weird.

So, if my guess is right, it isn't surprising that nobody has complained 
-- except that it seems to work for you (and Earnie).  Since ya'll are 
the maintainers of the packages in question, I suppose that's the 
important thing; as long as it's working for you...

> I just tried it for a couple of things but I don't have
> anything working well enough right now to try a full install.  I'm
> still trying to track down a gcc 3.1 bug and my dll is really screwed
> up.

Sorry to hear that -- but I'm glad somebody is working on cygwin+modern 
gcc. :-)


More information about the Cygwin-developers mailing list