Hi Przemek,
Before I read through your mail, let me note this is group
work, and while I'm familiar with some parts of it, I'm
not with some others, and no such implications (namely
the tie in between lib name and dir name in core) were
visible (or noticed by anyone), before the fact. I don't
think killing anyone would solve anything, but before you
jump to my throat notice that I haven't touched any central
GNU make (.cf) files, _only_ 'Makefile's LIBNAME line.
I doubt the file loss was the result of that.
I'm sorry if the whole process resulted in file losses
for you :( Unfortunately bumps are expected, even if I
find it odd that our make system can be such a dangerous
beast.
I had actually expected (but definitely hoped) you to take
part in this rename process because of your different
environment and skills, especially after you've agreed
and even gave input to it.
About a "simple file rename" I don't know what you
meant, but if you had exposed this idea _before_
or _when_ we've been discussing the rename stuff,
maybe could have a better solution.
About GTI_ and HB_GTI. GTI_ violates one important
rule and nothing was removed, so either on C and
Harbour level everyone can still use GTI_, despite it
being an xhb compatibility set of #defines imported
to Harbour. So the path is there for the Harbour compliant
way, yet no one suffers from any drawbacks. Where do you
see a problem?
Sorry but I don't find it normal that we're distributing
header files from other packages. This can be quite unsafe,
needs constant maintenance, gives the notion these are local
file, and they get locally modified eventually (they in fact
got modified in case of ADS), and last but not least it can
be _illegal_ (for ADS it definitely is).
The only one unsafe thing was your recent modification in make system
which breaks whole GNU make builds in a day before expected release.
I saked you to make modification only if you can make it well and they
will work. After two weeks we still haven't resolved all problems
introduced by this modification. Meanwhile I lost half of my home
directory due to typo in modified make files. Only half because when
I'd seen error messages that make cannot remove:
/boot, ... /etc, ... home/dominika, ...
I immediately break it. I lost whole xHarbour tree with a lot
of code which was never public and many other things. Fortunately
some libraries like extended DBRMAP or DBFNSX I had also on my
production machine but HBFLEX3 seems to be definitely lost :-(
I haven't answer immediately because I really want to kill you ;-)
People waiting for months with serious modification waiting for
end of release process and you are making such deep absolutely
untested modification which force to many other modifications
to resolve very minor problem which could be resolved by anyone
by simple file rename. In summary it was not big problem for me
but but the last minute fixes created incredible serious one.
I also asked you few times to not touch GTI_* defines and leave
it as is without HB_* prefix. I updated Harbour to compile with
strict ANSI mode, f.e. also changing ace.h - you remove it.
I added hbzlib and adsrdd to default builds because this are
vary important libraries for many users so they were included
in all official releases on all platforms even if packager did
not have some libraries installed, f.e. on some *nix systems
I do not have sufficient privileges to install any new devel
libraries but with header files in Harbour SVN directory I was
able to create full functional binaries. Similar situation is
is in cross build environments.
I know what will happen if sth will be changed in 3-rd party
code but:
1. authors of these two libraries intentionally keep binary
compatibility for years to avoid such problems so in this
case you haven't help any one but only created new problem
by removing them.
It's still not legal, and it still raises some other concerns,
and binary compatibility is by far not guaranteed, what happens
with the new functions added to ADS8 .h file, when someone is
using an ACE6 .dll with it? What happens when someone is passing
a non valid (later introduced) #define with an existing function?
If someone wants to create a release (which supposes some
familiarity with both Harbour and it's contribs and make
systems), is it a very high expectation to set a few envvars
and to have these two packages installed?
You still haven't answered what are the "serious problems"
these "missing" headers can cause. I'd really like to see them :(
2. when we finished release process then you can remove them.
I will not be longer interested what will happen in the main
branch because I plan to create new one only for development
If you will find anything useful then you can borrow it to
official branch.
I'm not exactly sure what do you mean by that? An internal fork?
And please also look for someone who will continue release process.
I'm afraid that I do not have more time for it. Now I have to restore
many things I lost which are important for me.
:(
I feel our GNU make system is flawed or overcomplicated if it can
cause such things.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
