Mail Archives: djgpp/1997/01/16/12:56:41
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>
> On Wed, 15 Jan 1997, Scott Blachowicz wrote:
>
> > Actually, I was thinking of adding a "dosify" function to GNU make that
> > could do string conversions...
> >
> > DOS_INCLUDE_DIRS := $(dosify $(INCLUDE_DIRS))
> > MSVC_INCLUDE_OPTS := $(addprefix /I ,$(DOS_INCLUDE_DIRS))
>
> By `dosify' do you mean converting the slashes to backslashes? Then just
> use $(subst) built-in.
Not just that though...you can have paths like //c/sources/subdir/file.c
and that //c needs to get converted to c: as well. I could do it with a
series of regexp based substitutions, but subst/patsubst are a little too
primitive. So, I would describe "dosify" as a convenience function that
does a series of regexp substitutions on a toolkit path to get it
transformed into a native DOS path. There's also other little tricks you
might want like transforming /dev/tty into CON:, but that's relatively
minor. I could, also, always just $(shell dosify $(INCLUDE_DIRS)) but
that's kind of an expensive operation.
> You might discover that the Win32 version of make already supports the
> backslashed pathnames, but I'd recommend to stay away from them as much
> as you can, because their support is incomplete (and cannot be made
> complete because it conflicts with some fundamental Make features such
> as filename wildcards etc).
Not to mention having colons in filenames...
> IMHO, using ported GNU tools which support forward slashes is the best
> solution (and also will let you stay sane, especially if you work on
> Unix from time to time).
Yes, but I also need to use some native DOS tools which tend to like
backslashes so I need some string conversion functions or tools that don't
mind taking either style of path.
> > but I never seem to have time to do more drastic changes...I think it'll
> > end up being feasible to use the Cygnus stuff, but it's a little work and
> > it'd be a lot easier if someone else did the work of getting DJGPP to do
> > the trick under NT 4 (which I would do, but I'm severely lacking in the
> > background necessary to put it together).
>
> If you need the entire GNU toolchain (or large parts thereof), it might be
> useful to try to enable LFN on NT from DJGPP library, because then you
Do you have a handy bit of code that could auto-detect the condition of
"running under NT"?
> just relink the available DJGPP ports and get a coherent toolset. If the
> LFN/NT project is too much for your resources, I'd recommend to compile
> the DJGPP-patched sources with MSVC. You will have to write a custom
> replacements for some library functions, because the DJGPP ports rely on
> the extended functionality of its libc to save some porting pains (a
> notable example is `stat' and `fstat'), and I doubt that MSVC library has
> something to offer here, but you can just use the source of DJGPP libc.
Yeah...I noticed that in poking around (the 'struct ffblk', for instance,
if I remember correctly). At the moment, impending deadlines make "build
on Win95" the most viable choice, but eventually I'll need to readdress
this. And it seems as though my choices are
1) switch to the Cygnus gnu-win32 toolset.
2) add LFN suppoprt for NT DJGPP.
3) see if a MSVC built GNU make works well enough.
4) work with the old, unsupported "Hippix" toolkit (the company went under
and their software is available for FTP, if I remember correctly) - I
know that had a GNU make it, but it had a few serious bugs.
5) find some other package with a GNU make in it?
6) punt and drop back to using MKS Toolkit's make.
Thanx!
Scott Blachowicz Ph: 206/283-8802x240 Mathsoft (Data Analysis Products Div)
1700 Westlake Ave N #500
scott AT statsci DOT com Seattle, WA USA 98109
Scott DOT Blachowicz AT seaslug DOT org
- Raw text -