Hi Marek,
I still don't agree with you on this.
To build rddads.lib someone will need the ACE
package from (now) Sybase installed. This package
has the .h and the .dll (the one to be distributed
with the final apps!). Harbour build process will
find both the header and the .dll and build the
RDD and the lib belonging to the .dll. Everything
matches. A final app can be built.
From that point on though, it's the developer's
responsibility to assure that the above .dll gets
found by his/her final application (by distributing
and installing the .dll with the app). If this is
done successfully, nothing like describe below would
happen.
And this goes for all libs requiring a .dll.
Relying on ace32.dll to magically match our
applications requirements is not very good.
Notice this was the first such "complaint", and it
could have happened just as easily if someone
picks up the shipped .lib from the package (if
there is any matching one for his/her compiler),
or someone did the conversion manually, but by
using the a different .dll.
My impression is that this feature makes good for
all those folks trying to effortlessly build a contrib
from the source. This is an experience unfortunately
rarely found on most OSS projects (at least on Windows).
It also makes my testing/build cycles way faster when
dealing with contribs, to add my personal side to it.
This is one reason I'm actually dealing with them
lately.
I will do one thing in next commit: I'll modify the
rddads build files to look for the .dll only in the
specified ADS_DIR, never in system32. Currently
latter was only used if the .dll couldn't be found
at any known places inside ADS_DIR.
And one other idea to the end, which may resolve
your concern:
Since it would be better to split the envvars for
headers and .dlls anyway, maybe we should consider
doing this and in this case .lib would only be
generated if the DLL_DIR was set. If this turns out
to be a bad move, we can still set the DLL_DIR
automatically, just as it is now.
Brgds,
Viktor
On 2008.05.08., at 13:19, Marek Paliwoda wrote:
Hi,
The problem here is that ace32.dll (found at runtime)
and ace32.lib (used at link time) is mismatched.
For best results it's good to have ace32.dll, ace32.lib
and ace.h matched at compile time of rddads.lib and link
time of final app, and later ace32.dll and the final
application kept matched.
Unfortunately this is exactly what I was trying to explain to
you - without success, but with a lot of completly unnecesary
flame wars. The whole idea behind automatic *.lib creation from
a dll during a compile time is plainly wrong (if not stupid).
I am still in a position that it *should be removed*, and - when
I get better - I'll return to this problem once again, asking the
group for its opinion once again.
--
Marek
----------------------------------------------------------------------
Andrzej Piaseczny w roli kucharza? Zobacz!
http://link.interia.pl/f1dcb
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
