Mail Archives: djgpp-workers/2000/04/09/02:24:49
On Fri, 7 Apr 2000, Juan Manuel Guerrero wrote:
> I don't know if anybody else have noticed
> that it has become IMPOSSIBLE to run the
> install target of gnu makefiles.
I haven't noticed; it works for me.
> Suppose the path that should be created by the install target is:
> /dev/env/DJDIR/foo
> The install target usualy invokes the file mkinstalldirs which
> invokes mkdir form fileutils. mkinstalldirs splits the above path
> into:
> dev env DJDIR foo
> and now mkdir REALLY tries to create everyone of the above
> directories step by step. In the root dir a /dev dir is created
> and then mkinstalldirs or mkdir breaks when it tries to create
> the subdir /env.
I don't understand. As far as I could see, mkinstalldirs creates the
following directories:
/dev
/dev/env
/dev/env/DJDIR
The first one is indeed created in the root directory. The second
causes `env' to be created in the current directory. The third simply
does nothing because the $DJDIR directory should already exist on any
system where DJGPP is installed. But nothing breaks as the result of
this.
It is true that the /dev and env directories pollute the disk a bit,
but except for this small inconvenience, where is the problem?
> Once again, neither mkdir nor ginstall understand the prefix:
> /dev/env/DJDIR
> and they do not replace the prefix by its appropiate value.
You can rebuild Fileutils, if you want them to support /dev/env.
> This
> implies that no user can run an install target from a makefile
> that uses the above prefix if he does not recompile fileutils
> BEFORE using mkdir.
As I said above, I don't see this problem, neither with the old
Fileutils nor with binaries rebuilt with v2.03. But in any case, you
can always say "make install prefix='${DJDIR}'". There's no need to
hack the Makefiles or mkinstalldirs.
> This shows that at least fileutils should be recompiled with libc 2.03
> and uploaded to simtelnet.
I agree that it would be nice if every GNU package could be updated on
SimTel.NET. Unfortunately, I don't have enough free time to do it all
alone. Since DJGPP v2.03 was released, I updated/ported the following
packages:
Make 3.78.1 and 3.79 (to be released promptly)
Texinfo 4.0
FAQ 2.30
Gawk 3.0.4
Grep 2.4
Diffutils 2.7.2
WMEMU
Textutils 2.0
Emacs 20.5
Tar 1.12a
Less 340
Man 1.3
That's 13 packages in less than 3 months, an average of 1 package
every week!
In addition, I have Patch 2.5.4, Id-utils 3.2d, and recode 3.5 in the
queue in different stages of readiness, and I'm working on GDB 5.0
(soon to be released), on Emacs 21, and on Gawk 3.0.5, with the
respective maintainers. On top of that, there's the usual traffic on
comp.os.msdos.djgpp with people who need help getting their projects
done. And I didn't even begin talking about my day-time job, my family,
and all the rest of my life.
Does it come as a surprise that I cannot do more by myself? Does
anyone feel the need to volunteer to help?? Please feel free to take
some of the load and make it happen faster. You will hear nothing but
applause from me.
> /dev/env/DJDIR -> ${DJDIR}
> /dev/x -> x:
> This is needed even if fileutils are recompiled
> with libc 2.03 because mkinstalldirs creates the
> path directory by directory.
Mark Elbrecht submitted a patch for `mkdir' in the library that would
take care of some of these problems. But I don't have time to check
in Mark's patch, either (or do any other library-related work, for that
matter), for the same reasons I didn't yet re-port Fileutils. In fact,
for quite some time I cannot begin any project that would move DJGPP
forward in any significant way--I simply don't have time for that.
It's high time for others to step forward to help keep DJGPP going[1].
Today seems like a good day to start. ;-)
[1] To be accurate, a couple of people did step forward: Andris
handles GCC and RHIDE; Mark takes care of Bash, Readline, and Binutils,
Prashant TR ported Indent and works on Sh-utils. All of these are
formidable tasks, and it's great they are taken care of; but it
obviously is not enough.
- Raw text -