On 6/3/2010 12:22 PM, Keith Marshall wrote:
> On Thursday 03 June 2010 00:51:18 Charles Wilson wrote:
>> Well, a mingw version of man could run in regular cmd.exe session.
>
> Up to a point, perhaps.
[mingw-man requires a posix shell, /somewhere/]
> http://mingw.cvs.sf.net/viewvc/mingw/man/src/win32/wincmds.c?view=markup
OK...
>> the
>> MSYS version is compiled with -DNONLS...[otherwise] man-1.6f
>> does try to use
>> catgets -- but I don't know if that is what you mean by "full"
>> support.
>
> Insofar as man's own message catalogue processing goes, yes.
OK...
> In addition, my port attempts to deduce an ISO-639 language code,
> from the Windows locale, and assign it to $LANG...see
> http://mingw.cvs.sf.net/viewvc/mingw/man/src/man.c?r1=1.8&r2=1.9
That's similar to what cygwin-1.7 now does, IIRC. I wonder if, for our
purposes, that functionality could be put in a library so that mingw (or
msys) clients could use it with minimal invasiveness. E.g. one-line
patch to add a call to mingwSetLangFromWin32LocaleUnlessPreset() in main().
>> Obviously this lack could be fixed with an msys port of your
>> catgets package, but I haven't done so. You weren't thrilled when
>> I ported man to msys in the first place, so I didn't push it.
>
> That was because I consider that a mingw32 implementation is a better
> fit for our "minimalist" policy.
Well, the main reason I ported (both man and groff) to MSYS was that I
kept running in to issues with mingw-man, which the msys port did not
seem to have. HOWEVER...now that I've switched universally to using
Console2 rather than rxvt, I begin to wonder if the problems were
actually with *rxvt* all along, and not mingw-man at all.
> Of greater concern to me was your
> MSYS port of groff, lest it would conflict with my requirement for a
> fully functional, pdfroff capable implementation,
Well, three points there:
1) There is no pre-compiled mingw-groff, you have to build it yourself
to use mingw-man. I don't think that's really acceptable.
2) All we have is a groff mingwPORT. Now, I have built it (obviously)
and IIRC it had a compiled-in prefix of C:\MinGW (or whatever the
end-user sets in mingwPORT.ini). I'm not sure if it uses that
compiled-in value, or some more intelligent "locate the exe and deduce
from there" to find its macro files and fonts, but in any case -- it's
not going to use the stuff in /usr/share/groff/. Also, if you install
mingw-man and mingw-groff in /mingw, then (in ordinary cases) you'll
always use mingw-man and mingw-groff, in preference to anything in /
like msys-man and msys-groff.
3) Err...none of the groffs I've ever been able to build for MSYS or
MinGW had pdf support. I'm kinda hazy, but don't you need a ghostscript
implementation in $PATH? Since we don't provide one officially, a
precompiled binary we ship -- e.g. mingw-groff -- can't assume that one
will be available on the target system. How do we express that
dependency in the xml manifest?
> (which is my own
> principal motivation for using MSYS at all, in my workplace -- all of
> the in-house documentation I produce is PDF, fully indexed with PDF
> bookmarks, and cross-references, in a manner which neither MS-Weird
> nor any other WYSIAYG package could aspire to achieve).
Which tells me you have a local, specially-built groff that is not
available to the rest of us. Now, MAYBE we could ship a full-featured
mingw-groff with all the bells and whistles (e.g. pdf and TeX support),
assuming that the packager builds on a system with gs32c in $PATH, and
MikTeX in $PATH. Then, end users would simply be told (in the
documentation, not the manifest) that for certain features to work, they
need to install these other tools from those other projects, and put
them in $PATH too. (*)
Which...is neither self-sufficient of us, nor minimal.
Hence, the bare-bones msys-groff without any of that support, and just
enough in its -bin package to enable msys-man (and, presumably,
mingw-man in the absence of any other groff earlier in $PATH) to work
properly.
As it stands, mingw-man is completely inoperable without "some"
groff-bin, and the only one we ship is the msys version.
(*) An alternate "solution" is to assume that mingw-man WILL use the
"crippled" msys-groff. Highly sophisticated users -- like yourself --
may instead choose to compile a more capable mingw-groff using the
mingwPORT and whatever GS/TeX tools are on their system, and install
that into /mingw. There, it would take precedence over the crippled
groff for both man and whatever else they want to use groff for.
But that's an end-user decision, and imposes no additional requirements
on us -- we don't even HAVE to ship any mingw-groff at all, much less a
full-bells-and-whistles version that EXPECTS non-MinGW.sf packages
installed "somewhere".
>>>> Ditto with MinGW/catgets/*
>>>
>>> Disagree. This is the i18n implementation for man, but it is a
>>> fully POSIX conformant, free-standing gencat/catgets
>>> implementation for Win32; it still merits a place, (not everybody
>>> wants to use gettext, and I plan to use this for mingw-get
>>> itself), perhaps repackaged to suit mingw-get's identification
>>> semantics.
>>
>> Actually, that's exactly what I meant: I think that the stuff under
>> MinGW/ and MSYS/ should all be *current*, and
>
> Well, the 1.0.1 version of catgets which is there *is* current
Well, again my imprecision is causing a problem. By "current" I meant
builds-and-works-with-currently-distributed-tools.
By that standard, PROBABLY both catgets-1.0 and catgets-1.0.1 are
"current" (**). But I wasn't sure, and the only "clue" I had was
whether the package names came anywhere close to the "new" standard we
hashed out almost a year ago.
If it didn't meet that standard, I assumed "more than a year out of
date: not 'current'".
(**) although, as a C library, the 1.0 and 1.0.1 versions were compiled
using msys-gcc-2.95.3. While that's *probably* ok when linking clients
built using msys-gcc-3.x, there was a ABI break between the
cygwin-derived gcc-2.x and gcc-3.x distributions, which affected both C
and C++ code. It probably only shows up in extreme corner cases, but it
does exist.
> -- we
> could drop the 1.0 version, leaving 1.0.1 as the only one. From that
> base, it is also maintained; I wrote it, and if it needs any further
> work, I will support it.
Well, of course. I took it as given that you, once you dug out from
under your current mingw-get work, would update any of "your" packages,
if necessary, to work with mingw-get. My assumption was that it IS
necessary for catgets.
Maybe it isn't -- I had forgotten about the
<release tarname="name that meets packaging standard">
<download tarname="actual tarball name that does not" />
</release>
construct (tho my ABI concerns remain).
> Even packaged as it currently is, it is as mingw-get compatible as,
> say GCC-3.4.5; mingw-get has been able to deliver a fully functional
> installation of *that*, since alpha-1 hit the mirrors. While the
> package breakdown, and naming conventions may not fit our current
> standards, that need not preclude mingw-get compatibility; it needs
> an appropriate manifest, but the interim lack of that is hardly
> sufficient reason to hide/withdraw the current package.
Ah, right: the <download /> tag. So, the only REAL bar to
"compatibility" is "do the contents of the tarballs go into the right
place?"
With regards to that, it looks like the answer is "yes, mostly". I might
quibble with the "split"; I think there should be separate -dll, -lic,
and -doc packages rather that just -bin and -dev, but that's the
decision of the actual maintainer. I.E. you.
The only REAL problem I see is that both the -bin and -dev packages
duplicate certain documentation, which will cause issues with
mingw-get's uninstall capability unless you implement the file-ref-count
proposal.
--
Chuck
|
