Hi Lorenzo,
Do you really find a change like this between beta3 and RC necessary
and needed?
It could certainly help in the future that such concerns
would be expressed before deciding about these changes,
yet, all I got was silence (from you) and a few approvals.
Silence used to be considered "okey", "no concern" or
"I don't care".
All the "users" will need to update their makefiles, projects and/or
batches/scripts to the new lib names and replace all the GTI_ to
Since we have a problem which we would need to solve eventually
anyway, what is the better time for it: Before 1.0? or after 1.0?
I think "before" suggests a more mature approach for any projects.
And the overall work to be done for all developers is at least
the same for both cases, but probably less with the "before"
approach.
HB_GTI_ for what if the developers are "looking elsewhere"?
Not true. See below.
For me "old" names where consistent with Clipper lib names:
1. dir source/rdd/dbfcdx creates lib dbfcdx
2. in the source there is
REQUEST DBFCDX
rddSetDefault( "DBFCDX" )
First of all this haven't changed. Second, we have
RDD names which don't have anything to do with
the lib name ("DBFDBT" for one example), if that's
what you are saying. Since one RDD lib file may
contain multiple RDD names, syncing these names
cannot be a goal.
3. in the Clipper 5.x drivers guide the drivers is called DBFCDX in
all examples
Well, all of our filenames differ from CA-Cl*pper
for that matter. Except the header files of course.
This is for a purpose.
I find it very odd to name our libs the same way as
Clipper, as this was for example making it impossible
to use a common LIBRARY envvar pointing to both the
CA-Cl*pper libs and the Harbour ones (for BCC32, MSVC,
and probably more).
Now after 8 years and 3 betas the lib become suddenly rddcdx.
I think we should rename the libs as they were and revert HB_GTI to
GTI_.
1.0 RC should be usable by a beta3 user without any modification.
GTI_* is _still_ available the same way as it was. The only
thing changed is that it's now in "compatibility" status
rather than "primary" status, and those who have collisions
can _explicitly_ and optionally switch them off. I'm writing
this the 3rd time, first time being the ChangeLog entry itself.
Maybe I wasn't clear enough.
Again: GTI_* _still_ _do_ _work_. App code _doesn't need any
modification_ to compile (both C and Harbour).
The only implication is that in Harbour core/contrib code,
HB_GTI_* usage is encouraged (but GTI_* would still work).
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
