Quoting Lennart Borgman <lennart.borgman.073@...>:
> Thanks, it makes me curious, I wonder what Earnie have against it.
> The current solution makes it a bit difficult to compile newer
> versions of for example Diffutils.
>
> I looked in MSYS packages/diffutils but I could not find any
> configure.guess. What is the reason for this? Is it somewhere else?
>
I don't know where the config.guess and config.sub have gone. I certainly
didn't mean to leave it out. Copy the config.guess and config.sub from
msysDVLPR package into the top source directory.
Earnie

Quoting Lennart Borgman <lennart.borgman.073@...>:
> config.guess timestamp = 2002-03-20
>
> uname -m = i686
> uname -r = 1.0.10(0.46/3/2)
> uname -s = MSYS_NT-5.0
> uname -v = 2004-03-15 07:17
>
> /usr/bin/uname -p = unknown
> /bin/uname -X =
>
> hostinfo =
> /bin/universe =
> /usr/bin/arch -k =
> /bin/arch =
> /usr/bin/oslevel =
> /usr/convex/getsysinfo =
>
> UNAME_MACHINE = i686
> UNAME_RELEASE = 1.0.10(0.46/3/2)
> UNAME_SYSTEM = MSYS_NT-5.0
> UNAME_VERSION = 2004-03-15 07:17
> configure: error: cannot guess build type; you must specify one
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
FYI, O_TEXT using the MSYS runtime is meaningless as MSYS forces binary
mode I/O
regardless. There are reasons I decided to do this that I don't have time to
explain now.
> Should we send this to gnu.org to get MSYS into configure.guess? Is
> this maybe already done?
>
No, and no again. I've asked the maintainer of config.guess and config.sub to
not accept such patches as the MSYS target is a private case.
> I do not know what more should be provided to them in order to get
> this working?
>
Unless you read the end of the line and handle the line ending to make them
match you won't get it to work as an MSYS application. I purposely made them
work as it would on a POSIX system since MSYS is emulating a POSIX
environment.
The best method to handle this is as Keith has suggested. If the files have
different line endings then make them have the same line endings before
executing diff. That process has been used since DOS was created and we
started passing files back and forth.
Earnie

Greg Chicares wrote:
>It doesn't seem to be implemented in MSYS's diff:
>
> diff: unrecognized option `--strip-trailing-cr'
>
> diff - GNU diffutils version 2.7
>
>but the manual you cite is for version 2.8.1, so maybe porting a
>later version of diffutils to MSYS would resolve the issue in the
>way the majority seems to prefer.
>
>
I am not sure. Perhaps that depends on the decisions made in the
configure process?
After having a look at the build process for MSYS packages, the
difficulties with updating those packages, the problems with
portability, the choices for the rules on w32, the differences between
GnuWin32 tools and MSYS dito, ect -- then I am beginning to wonder what
I am actually doing!
A while ago someone (sorry I forgot the name) said that some of the
GnuWin32 tools can be used together with MSYS. I asked which tools but
we did not find a clear answer. Maybe it would be good to look into this
very carefully? I have got the impression that the GnuWin32 tools are
compiled right out of the box -- with the help of MinGW+MSYS. That is a
big advantage and makes it much easier to use the most up-to-date
versions of the GNU utilities.
Some tools need to use the MSYS-1.0.DLL, but which are they? What
requirements make this necessary? Is there for example anything that
makes it better to use a diff compiled for MSYS than one compiled for
native w32?
I guess those starting other processes are candidates for the group that
requires the MSYS-1.0.DLL. But what about those that does not start
other programs? They should (at least in theory) get the file paths in
native w32 format.
So what is actually the reason today that there is a special MSYS
version of diff (for example)? Why not try to marry MSYS+GnuWin32? The
couple already seems dependent on each other... ;-)
Kind regards,
Lennart
PS: Is there some special kind of dependence between sh and make?

On 2005-10-12 13:24 UTC, Leif W wrote:
>
> 1) Binary (-q or --brief: simple yes or no if they differ)
> 2) Text (--binary: distinguish between EOL)
> 3) Text (-a or --text or maybe --strip-trailing-cr: "disregard" EOL)
I had never noticed the '--strip-trailing-cr' option before, and it
doesn't seem to have come up in this discussion until now. It sounds
very much like this idea:
On 2005-8-5 14:15 UTC, Earnie Boyd wrote:
> 4) Treat \n and \r\n as different unless some special switch is applied
It doesn't seem to be implemented in MSYS's diff:
diff: unrecognized option `--strip-trailing-cr'
diff - GNU diffutils version 2.7
but the manual you cite is for version 2.8.1, so maybe porting a
later version of diffutils to MSYS would resolve the issue in the
way the majority seems to prefer.

Keith MARSHALL wrote:
>It's `config.guess', not `configure.guess'. Any package which
>attempts to do canonical host resolution, as diffutils apparently
>does, is supposed to ship copies of both `config.guess' and
>`config.sub', so they *should* be in the MSYS package;
>
>
Thanks, no I can not find any config.guess in MSYS packages/diffutils.
>The GNU `diff' manual is a `cop-out'; sure, it refers to an intent
>for processing text files, but it doesn't define what is meant by
>`text'. I have always understood this to mean files with a line
>oriented structure, *regardless of the EOL marking protocol*; even
>Microsoft understood it this way, when they provided the `fc' or
>`filcom' utilities in MS-DOS, a binary compare was byte by byte,
>and as soon as a difference was found there was no attempt to
>find any subsequent match, whereas a text mode compare would
>attempt to resynchronise after a line boundary.
>
>
Ehum, to avoid more trouble can you first explain "cop-out"?
And it seems to me that you agree with me about what a line is?
>...then you might think so. However, the Oxford English Dictionary,
>(which is the definitive reference source for those of us who speak
>the British variant of English), defines it as an agreement based on
>a *majority* opinion, which seems more in tune with how Leif actually
>understands it...
>
>
Yes, I can see now we did not use the same definition of "consensus". I
was quite confused by that and found the answers a bit impolite ;-)
>>Some afterthought: Could the problem that this was left has it roots
>>in that MSYS truly tries to be a "GNU environment" on w32 that looks
>>very much like the environment on GNU/Linux? Could it just be that
>>some fine tuning should be made because of the fact that the
>>underlying system in fact is w32?
>>
>>
>
>You are probably getting close to the nub here. MSYS strives to provide
>a GNU build environment on Win32 -- and that build environment is based
>on text files with lines delimited by LF, *not* CRLF.
>
>
I remember Earnie somewhere wrote that his goal was a building
environment. I am trying to stretch that a bit to use it for more
interactive use also, inside and outside of Emacs. For that too work
good integration into the outside w32 environment is necessary. One of
the things needed is the capability to cater for w32 style line endings too.
I of course want to achieve this without breaking Earnies initial goal.
I can see there can be subtle breaks. Unit tests are the way to go here
I believe.
I have yet too see an example of where treating LF and CRLF breaks
anything, but it is possible. As I have pointed out I would be glad for
a realistic example.
>Leif has mentioned possible contentions with CVS. Diff is used, whether
>directly, or indirectly via CVS, to create patches. This is the *real*
>crux of the matter -- patches *absolutely must* conform with the line
>ending protocol used in the CVS repository, which 99.99% of the time is
>LF, and not CRLF. Therefore you need a diff which *guarantees* to use
>this protocol. If your diff silently ignores differences between LF
>and CRLF, or worse still emits CRLF, then sooner or later you are going
>to be submitting broken patches, and project maintainers are going to
>simply reject them, not because your idea is flawed, but because your
>patch is broken.
>
>
This is one of the reasons I want a diff that can handle any line
endings. Then I do not have to convert line endings format back and
forth and maybe forget to change them back.
Hm, mabye that example of ignoring the different line endings is a
realistic example... - But does not CVS take care of this? Again, I am
not an expert, but somewhere in my head is a little reminiscence of some
reading about that.
Kind regards,
Lennart

Lennart Borgman wrote:
> Would "diff --version 2>&1 || echo Not GNU diff, unknown version"
> be a useful solution?
diff --version 2>/dev/null || echo "non-GNU diff; version unknown"
would probably be better, unless you *really* want to capture the
"illegal option" diagnostic from the non-GNU diff in your test log.
>> You should also be aware that the shUnit test framework you have
>> employed will, itself, crash the standard shell on many current
>> (and older) BSD systems; (this is because the ${varname:-value}
>> construct is not permitted -- only ${varname-value} is allowed).
>
> That is a pitty [sic]. I do not want to change this myself but can
> try to carry it back to the maintainers.
You should do -- it's a portability issue of which they should be be
made aware.
> However I believe there [sic] main target is Posix compliant systems.
They claim to support the Bourne shell family, although they do state
"all POSIX OSes". Unfortunately, the Bourne shell *isn't* POSIX, and
if you want real portability, you cannot assume *any* level of POSIX
compliance; (POSIX is more closely related to the features of the
Korn shell, than to the Bourne shell).
Regards,
Keith.

Lennart Borgman wrote:
> I looked in MSYS packages/diffutils but I could not find any
> configure.guess. What is the reason for this? Is it somewhere
> else?
It's `config.guess', not `configure.guess'. Any package which
attempts to do canonical host resolution, as diffutils apparently
does, is supposed to ship copies of both `config.guess' and
`config.sub', so they *should* be in the MSYS package; (I don't
seem to be able to access the CVS at the moment, to check, and I
don't have a checked out copy of the appropriate module).
> I did not want to force diff to use text mode for cases.
> In this patch I tried to follow the GNU diff manual (but maybe
> there is some bug in this version of Diffutils?).
The GNU `diff' manual is a `cop-out'; sure, it refers to an intent
for processing text files, but it doesn't define what is meant by
`text'. I have always understood this to mean files with a line
oriented structure, *regardless of the EOL marking protocol*; even
Microsoft understood it this way, when they provided the `fc' or
`filcom' utilities in MS-DOS, a binary compare was byte by byte,
and as soon as a difference was found there was no attempt to
find any subsequent match, whereas a text mode compare would
attempt to resynchronise after a line boundary.
> I know this is not what was seen by you and several others
> consensus. (I just looked up the word "consensus". Does not that
> mean that all participants should agree?)
If you read the same definition as Leif W cites...
> Hmm, well, I looked at an online dictionary which defines it as
> being unanimity, solidarity, single opinion.
...then you might think so. However, the Oxford English Dictionary,
(which is the definitive reference source for those of us who speak
the British variant of English), defines it as an agreement based on
a *majority* opinion, which seems more in tune with how Leif actually
understands it...
> Never in my life have I intepreted consensus to mean this.
> Consensus for me has always implied majority, minority, difference
> of opinion, debate, compromise and the willingness to disagree (in
> part or in whole) and commit to action regardless.
...and this is how I have always understood it too.
> Some afterthought: Could the problem that this was left has it roots
> in that MSYS truly tries to be a "GNU environment" on w32 that looks
> very much like the environment on GNU/Linux? Could it just be that
> some fine tuning should be made because of the fact that the
> underlying system in fact is w32?
You are probably getting close to the nub here. MSYS strives to provide
a GNU build environment on Win32 -- and that build environment is based
on text files with lines delimited by LF, *not* CRLF.
Leif has mentioned possible contentions with CVS. Diff is used, whether
directly, or indirectly via CVS, to create patches. This is the *real*
crux of the matter -- patches *absolutely must* conform with the line
ending protocol used in the CVS repository, which 99.99% of the time is
LF, and not CRLF. Therefore you need a diff which *guarantees* to use
this protocol. If your diff silently ignores differences between LF
and CRLF, or worse still emits CRLF, then sooner or later you are going
to be submitting broken patches, and project maintainers are going to
simply reject them, not because your idea is flawed, but because your
patch is broken.
Regards,
Keith.

> From: Lennart Borgman <lennart.borgman.073@...>
> Received: Tue, 11 Oct 2005 09:56:32 AM EDT
> that I had made rather clear that I did not agree, but I did not have =
> Maybe am I misunderstanding "consensus"?
Hmm, well, I looked at an online dictionary which defines it as being
unanimity, solidarity, single opinion. Never in my life have I inteprete=
d
consensus to mean this. Consensus for me has always implied majority,
minority, difference of opinion, debate, compromise and the willingness t=
o
disagree (in part or in whole) and commit to action regardless. And if n=
ot
part of any of that, it's fine to go off alone and do it yourself, but ac=
cept
what that also implies. ;-)
> Another reason for not replying promptly was that some of the replies =
> before the voting did have IMHO a smell of flame. I opted to stay out =
> because when flames are in thought is out.
Well for my part, sorry if it got like that. Anyone can get like that fr=
om
time to time. When flames are in, thought is out, I like that, good word=
s to
remember before posting.
> That is also why I could not =
> take the voting so seriously, but that might have been a mistake. =
Yeah, a mistake. Think of it like this. If people respond so strongly t=
hat
they temporarily lose some rationality, it may be a good indication of ho=
w
"strange" or "unorthodox" your request is perceived. ;-)
> On one hand I do not want to tolerate =
> flames because they disturb the work and time we offer. On the other =
> hand I did not want to flame back. This is a difficult balance.
Again, good ideas for us all to reflect upon before posting. With this r=
ound
of discussion I think you have walked that fine line well and so I've tri=
ed to
respond in like fashion.
> It is a said thing that there tend to be flaming on lists about GPL =
> software. It defeats the purpose I believe most of us have.
Well, it's great that people are passionate about the software. :-) And=
perhaps that energy is best spent in less combustible ways.
> My concern is with files moving between different operating systems. =
> That is of course how the problem we are discussing emerges.
Are you sure? I thought I heard mention of CVS, which raises the issue o=
f
update contentions with line endings. Does CVS use diffutils? Does CVS =
have
an option to accept various line endings? I don't know CVS that well at =
all. =
But if it's just files being passed around, the issue might still be ther=
e. =
But the files should be such a small number that it's little problem to h=
andle
with a conversion utility. If it's many files, should have some version
control, right? ;-)
> I do not =
> care much about right or wrong - the question is rather "what is
> useful".
In general in life, if a person sees black or white, they miss the infini=
te
possible other interpretations in the grey area. It's taken many years f=
or me
to appreciate this. But computers know only binary, and for people to
effectively program, they must think in binary (not literally, but the ri=
ght
way or best way is usually a discreetly defined and small set of
possibilities). When we come back to differences of opinion, we may stil=
l
process in this mode, and may exclude some possibilities or compromises. =
And
instead it turns into a struggle to define who is right or wrong, and
depending on how much importance that has for defining self worth, may yi=
eld
flamage. I've been there and done that too. :p
> In my opinion diff is mainly for comparing text, not line endings. That=
=
> is probably what most people use it for.
Well I've checked diffutils home page ( http://gnu.org/software/diffutils=
/ )
and it appears to be primarily designed to compare text files. But here =
we
have some ambiguity. We should clarify. There are three types of
differences.
1) Binary (-q or --brief: simple yes or no if they differ)
2) Text (--binary: distinguish between EOL)
3) Text (-a or --text or maybe --strip-trailing-cr: "disregard" EOL)
> The matter we are discussing is from my point of view =
> bigger than "diff in MSYS". To promote portability I would like GNU dif=
f =
> to have the same default
[snip: disregard EOLs :snip]
> should try to avoid making MS Windows the best platform for running GNU=
=
I do not think that will ever be a problem. :-)
> The reason for raising the question here is that I thought MSYS is a =
> good start and it can be integrated into MS Windows in a good way =
MinGW/MSYS is likely to be one of the few places around that is most
sympathetic to running any GNU/*nixy software in Win32 for the sake of
portability. Yet even here the question you propose is largely resisted.=
=
This should be considered. Think of the resistance you will receive if y=
ou
try to pose the question to GNU, or to any of the users of software that =
have
used GNU software (and in particular diff) in native *nixes for 10-20 yea=
rs
(or however long diff existed).
remind yourself, don't think of it as right or wrong. I believe your con=
cerns
are valid and have merit. But rather as you say, think of what is useful=
, and
as I say, think of what is realisticly achievable. That is the compromis=
e is
an integral part of consensus. ;-) I think the envvar or conf file migh=
t be
realistically achievable because of much less resistance. Then you can
configure the default behavior, without forcing other people to change th=
eir
opinion about what should be the official, compiled default.
This is one of those common, essential, unspoken, assumed ways of thinkin=
g in
*nix. Nothing will suit everyone, so give me options and I will use them=
=2E =
Never rely on defaults, but rather define my preferred behavior for a giv=
en
program with options.
> This are my reasons. I do not know if I have been sufficiently short an=
d =
> clear.
Likely shorter and clearer than me. :o
> However I would be glad for some convincing reasons why diff =
> should not behave as I have suggested. In what situations is it really =
> useful that diff thinks that files are unequal just because the line =
> ending format are not the same?
Again, this may be "binary" thinking: Either it's the same or it is not, =
so
tell me. It may just be a good exercise to practice discipline and preci=
sion
when working with computers. Without these things, programmers are likel=
y to
make sloppy work and have a hard time fixing bugs. I'm speaking from
excessive experience. ;-) So regardless of the nature of the diff behav=
ior,
the value of forcing the exercise with current defaults far exceeds the
convenience which allows for imprecision.
To paraphrase a movie:
Daniel-san, wax-on, wax-off, stroke up, stroke down, sand left, sand righ=
t. =
Now you see the value of these useless exercises?
> I have rewritten this as unit tests, see =
> http://ourcomments.org/Emacs/DL/MSYS/diffutils-2.7/LeifW/. The file =
> TestLeifW contains more information and the tests. (I was reading the =
> message from Leif W when I decided to rewrite my test examples to fit h=
is.)
Err, I did not test my test cases, I just invented them and followed the =
same
format as Earnie's. :p May need tweaking. But also, it's not a complet=
ely
exhaustive test of diff, and currently diff does not seem to respond well=
to
carriage-return all by itself, or at end of file. More comprehensive tes=
t
cases might be indicated. The number can get ridiculously high as I thin=
k of
combinations and permutations for discreet test cases.
3 cases for endings with 1 line per file yields: 3 files
compare 2 files at a time yields: 6 tests
3 lines per file (unique line endings) yields: 6 files
compare 2 files at a time yields: 30 tests
What about if we need 5 lines, such that we test the case when a line is =
not
adjacent to the first or last line. 5 lines per file, 3 unique, 2 repeat=
ed,
but which 2? Split again for permutations, or go to 6 lines, to avoid
choosing 2/3, and just double-up? Well, maybe fix (don't change) first a=
nd
last to \n (as \r and \r\n were tested earlier). Comes down to 6 files a=
gain.
30 more tests.
66 tests for diff, to be fairly certain about how it might respond in eve=
ry
possible scenario.
But that's just line endings. There might be embedded null or non-printa=
ble
characters which make diff treat it differently, no idea what -a might do=
=2E..
more test cases, more line combinations, more files, much more tests. :p=
Maybe worth it if it yields a mission-critical diff. :-)
Umm, paragraphs? Let's not joke... Ok maybe one paragraph can contain m=
any
of these combinations, thus reduce the number of files back to a sane lev=
el
less than 10.
Sorry for verbosity, thinking out loud.
Leif

Keith MARSHALL wrote:
>Your tests aren't sufficiently portable, to let that happen on
>any non-GNU flavour of UNIX.
>...
>
>
>>The output from these tests also contains uname -a and
>>diff --version to make this easier.
>>
>>
>
>`uname -a' is ok, (should be ubiquitous), but `diff --version'
>will choke with an "illegal option" exception, if I try to run
>it on SunOS/Solaris; similarly `diff -u' is not universally
>supported, (and will also choke on SunOS/Solaris). `diff -c'
>is more portable, (SunOS/Solaris *does* support it), but for
>ultimate portability you need to run a bare diff command
>*without* options.
>
>
Would "diff --version 2>&1 || echo Not GNU diff, unknown version" be a
useful solution?
>You should also be aware that the shUnit test framework you have
>employed will, itself, crash the standard shell on many current
>(and older) BSD systems; (this is because the ${varname:-value}
>construct is not permitted -- only ${varname-value} is allowed).
>
>
That is a pitty. I do not want to change this myself but can try to
carry it back to the maintainers. However I believe there main target is
Posix compliant systems. (And I should not change it because I do not
know this stuff that well!)
Kind regards,
Lennart

Keith MARSHALL wrote:
>I'll defer to Earnie on this; I know he is not keen to have the
>autotools explicitly identify MSYS, (as opposed to MINGW), as a
>publicly supported build system, but maybe config.guess should be
>an exception. If not, the MSYS sources should include a locally
>patched config.guess, (so that _they_ at least recognise their own
>native build environment); you should be able to drop this into
>the generic GNU source tree, to work around this problem.
>
>
Thanks, it makes me curious, I wonder what Earnie have against it. The
current solution makes it a bit difficult to compile newer versions of
for example Diffutils.
I looked in MSYS packages/diffutils but I could not find any
configure.guess. What is the reason for this? Is it somewhere else?
>Without having studied the original code, here are some initial
>comments on your patch:--
>
>1) It will never be accepted, if you don't accompany it with an
> appropriately formatted ChangeLog entry.
>
>
I keep that in my head, but this patch was just for comments.
>2) All you appear to have done is unconditionally force diff to
> use text mode for *all* I/O streams. This is diametrically
> opposed the the general consensus of opinion that the default
> behaviour of diff should remain unchanged.
>
>
That is just a mistake, I did not want to force diff to use text mode
for cases. In this patch I tried to follow the GNU diff manual (but
maybe there is some bug in this version of Diffutils?).
I know this is not what was seen by you and several others consensus. (I
just looked up the word "consensus". Does not that mean that all
participants should agree?) I think it makes sense still because we
where probably not aware of that part of the GNU diff manual that I
quoted in an earlier message before.
>>+/* I believe this should be set -LB */
>>+#define HAVE_SETMODE 1
>>
>>
>
>3) No, it shouldn't. This defeats the purpose of configuring the
> package. What should happen is that configure should check for
> setmode, using `AC_CHECK_FUNCS([setmode])', thus adding the
> `#define HAVE_SETMODE 1' to config.h, but only when it is
> pertinent. The purpose of this fragment in system.h is to
> ensure that, on systems where setmode isn't available, that
> `#if HAVE_SETMODE' works properly.
>
>
Yes, thanks, of course. I just meant that the configure process should
have set it.
Some afterthought: Could the problem that this was left has it roots in
that MSYS truly tries to be a "GNU environment" on w32 that looks very
much like the environment on GNU/Linux? Could it just be that some fine
tuning should be made because of the fact that the underlying system in
fact is w32?
> If configure isn't doing this, then you should either specify
> `-DHAVE_SETMODE=1' within CFLAGS, (on your configure command
> line), or better, patch configure.ac to add the appropriate
> test, and rerun autoconf and autoheader before you start.
>
>
I do not understand the organisation of things here. (And I do not know
configure.ac but that is not the trouble at the moment ;-) I can not
find any configure.ac in MSYS packages/diffutils. Is this some older
version of the configure scripts?
>5) The second `for' loop is redundant here; just write the first
> as:
>
> for (i = 0; i <= 1; i++)
> if (0 <= inf[i].desc)
> setmode (inf[i].desc, binary_I_O ? O_BINARY : O_TEXT);
>
>
Thanks, just my stupidity when I was in a hurry compiling.
>
>
>>This version works for the default (reading data as text) but fails
>>for --binary for some reason.
>>
>>
>
>Perhaps because your patch precludes the possibility of `binary_I_O'
>ever being set to one; (just a guess, at present).
>
>
Probably, I will fix that.
Thanks,
Lennart

Lennart Borgman wrote:
> Running the tests on different platform is a good idea. Doing
> that in the form of the unit tests I uploaded might be useful
> for collecting results.
Your tests aren't sufficiently portable, to let that happen on
any non-GNU flavour of UNIX.
> The output from these tests also contains uname -a and
> diff --version to make this easier.
`uname -a' is ok, (should be ubiquitous), but `diff --version'
will choke with an "illegal option" exception, if I try to run
it on SunOS/Solaris; similarly `diff -u' is not universally
supported, (and will also choke on SunOS/Solaris). `diff -c'
is more portable, (SunOS/Solaris *does* support it), but for
ultimate portability you need to run a bare diff command
*without* options.
You should also be aware that the shUnit test framework you have
employed will, itself, crash the standard shell on many current
(and older) BSD systems; (this is because the ${varname:-value}
construct is not permitted -- only ${varname-value} is allowed).
Regards,
Keith.

Lennart Borgman wrote:
> configure: error: cannot guess build type; you must specify one
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Should we send this to gnu.org to get MSYS into configure.guess?
> Is this maybe already done?
I'll defer to Earnie on this; I know he is not keen to have the
autotools explicitly identify MSYS, (as opposed to MINGW), as a
publicly supported build system, but maybe config.guess should be
an exception. If not, the MSYS sources should include a locally
patched config.guess, (so that _they_ at least recognise their own
native build environment); you should be able to drop this into
the generic GNU source tree, to work around this problem.
> I have tried to patch the current MSYS CVS version of
> packages/diffutils. [...]
> I have attached the "cvs diff -u" output.
Without having studied the original code, here are some initial
comments on your patch:--
1) It will never be accepted, if you don't accompany it with an
appropriately formatted ChangeLog entry.
2) All you appear to have done is unconditionally force diff to
use text mode for *all* I/O streams. This is diametrically
opposed the the general consensus of opinion that the default
behaviour of diff should remain unchanged.
> diff -u -r1.1.1.1 system.h
> --- 2.7/system.h 5 May 2002 17:03:08 -0000 1.1.1.1
> +++ 2.7/system.h 11 Oct 2005 23:22:33 -0000
> @@ -236,9 +236,12 @@
> #endif
>
> #ifndef HAVE_SETMODE
> -#define HAVE_SETMODE 0
> +//#define HAVE_SETMODE 0
> #endif
>
> +/* I believe this should be set -LB */
> +#define HAVE_SETMODE 1
3) No, it shouldn't. This defeats the purpose of configuring the
package. What should happen is that configure should check for
setmode, using `AC_CHECK_FUNCS([setmode])', thus adding the
`#define HAVE_SETMODE 1' to config.h, but only when it is
pertinent. The purpose of this fragment in system.h is to
ensure that, on systems where setmode isn't available, that
`#if HAVE_SETMODE' works properly.
If configure isn't doing this, then you should either specify
`-DHAVE_SETMODE=1' within CFLAGS, (on your configure command
line), or better, patch configure.ac to add the appropriate
test, and rerun autoconf and autoheader before you start.
> diff -u -r1.1.1.1 diff.c
> --- 2.7/diff.c 5 May 2002 17:03:02 -0000 1.1.1.1
> +++ 2.7/diff.c 11 Oct 2005 23:22:32 -0000
> @@ -555,8 +555,10 @@
> /* Use binary I/O when reading and writing data.
> On Posix hosts, this has no effect. */
> #if HAVE_SETMODE
> - binary_I_O = 1;
> - setmode (STDOUT_FILENO, O_BINARY);
> + //binary_I_O = 1;
> + binary_I_O = 0;
> + //setmode (STDOUT_FILENO, O_BINARY);
> + setmode (STDOUT_FILENO, O_TEXT);
> #endif
4) Only if this appears within the scope of the processing of a
new command line option, (which you haven't provided), which
explicitly activates the Win32 CRLF == LF operating mode.
> @@ -1064,6 +1066,10 @@
> for (i = 0; i <= 1; i++)
> if (0 <= inf[i].desc)
> setmode (inf[i].desc, O_BINARY);
> + if (!binary_I_O)
> + for (i = 0; i <= 1; i++)
> + if (0 <= inf[i].desc)
> + setmode (inf[i].desc, O_TEXT);
5) The second `for' loop is redundant here; just write the first
as:
for (i = 0; i <= 1; i++)
if (0 <= inf[i].desc)
setmode (inf[i].desc, binary_I_O ? O_BINARY : O_TEXT);
> This version works for the default (reading data as text) but fails
> for --binary for some reason.
Perhaps because your patch precludes the possibility of `binary_I_O'
ever being set to one; (just a guess, at present).
Regards,
Keith.