the time to make mine, you didn't bother to comment.
Please don't take it personal.
I've nothing against you, simply a msg like "what about removing xyz.
because ..." could help to ear different opinions "before" the change.
I used to do this when there is a shady matter,
but in this case it's a clear problem which should
be fixed (which shouldn't have been committed by me
in the first place, but I admittedly didn't notice
this regression until now).
The only unfortunate aspect of this, is that you
started to rely on this detail in your environment.
At this stage ( we're between beta3 and RC1 ) it's expected to have
only critical bug fixes and not changes to the command line arguments
Which this is.
that has worked in this way for a year.
I vote to keep -- and // as it was and move the "fix" after the 1.0
release.
IMHO it is a minimal issue that should not delay the release.
I think this is a pretty serious issue, since
existing apps break, and future command line tools
suffer (not my existing apps, apps in general, and
maybe my - and your - future apps). I think this is
higher priority that the current setup of you development
environment, sorry to say that.
I don't want to be a parrot, but please suggest
something which solves the problem on a generic
level. I've suggested --hb:gtcrs, --hb:info
(and //hb:gtwin, //hb:info, //gtwin, //info), which
seems a nice way solve this matter. For you it takes
one pass to modify your local scripts, once and for all.
(you could temp-ly apply a local patch as well, it's
just about two lines, and the file is pretty static, so
one patch file can last for a long time)
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
