Mail Archives: cygwin-developers/2002/02/13/13:57:22
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. :-)
--Chuck
- Raw text -