From: Charles W. <cwi...@us...> - 2010-06-04 17:28:44
|
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 |
From: Charles W. <cwi...@us...> - 2010-06-04 17:37:29
|
On 6/4/2010 1:28 PM, Charles Wilson wrote: > (**) although, as a C library, the 1.0 and 1.0.1 versions were compiled > using msys-gcc-2.95.3. blah blah other "ABI concerns" blah blah Oops. Forget this; we're talking about mingw-catgets, not msys-catgets. So the only ABI concern would be mingw-gcc-3.4.5 vs. mingw-gcc-4.4.x. Now, the same hack that was imposed in cygming-derived gcc-3.x and caused (part of) the break between gcc-2.x and gcc-3.x was REMOVED in mingw-gcc-4.x. So...we still have an ABI break. But, as has been demonstrated, it does not appear to cause any problems -- so far -- when using gcc-3.x-built libs with gcc-4.x-compiled apps. So, ignore the ABI issue. -- Chuck |
From: Keith M. <kei...@us...> - 2010-06-04 21:14:38
|
On Friday 04 June 2010 18:37:07 Charles Wilson wrote: > On 6/4/2010 1:28 PM, Charles Wilson wrote: > > (**) although, as a C library, the 1.0 and 1.0.1 versions were > > compiled using msys-gcc-2.95.3. > > blah blah other "ABI concerns" blah blah > > Oops. Forget this; we're talking about mingw-catgets, not > msys-catgets. So the only ABI concern would be mingw-gcc-3.4.5 vs. > mingw-gcc-4.4.x. Yep. In fact your presumption that it was compiled with gcc-2.95 is incorrect; it was compiled with gcc-3.4.5, and, as you noted at the time, it uses modern C idioms which preclude compilation by 2.95. -- Regards, Keith. |