Hi Przemek,

On Sat, 09 Feb 2008, Szakáts Viktor wrote:
I'll look into this header package problem tomorrow.
One thing that would help a lot here, is to have a
separate include dir inside the Harbour source tree,
which is empty in the repository, and where these
headers could be spilled from the 3rd party header
zip file.
Such a folder could be /include/3rdparty/ or
/include/usr/

I like the idea of separated subdirectory with some 3-rd party
header files. It will resolve the problem. And to be clear.
I do not want to put all 3-rd party header files in this directory
and in most cases I will vote against adding new ones. We can keep

I've actually proposed to leave this dir _empty_ in the
repository, so such decisions don't have to be made by us.
I my view, we should provide a list of headers separately,
as an easy download, with all the headers and license files
(which MUST be distributed with GNU stuff for example) and
other distribution stuff (if needed) packaged together, in
an easy to unzip way.

"Builders" would have to unzip this file to this Harbour
3rd party include dir locally, and start the process
without worries about missing headers.

Actually the only file I'd put in this dir in Harbour
SVN, is a .txt file pointing to the right place to go
for this header package.

3-rd header files only if our library is very important for many
users so it should be included in default builds and we do not have
to worry much about binary compatibility with different releases
of 3-rd party library. In this case (ACE and ZLIB) all these
conditions are passed. In the future we will have to add zlib
support to core code probably like hbpcre so it can be easy
replaced by native libraries. zlib support will be necessary
to implement some important features like online inet socket
compression or compressed memo files.

For zlib I think we could include it as well in core,
but I'd only vote to include the header if we would
include the whole source tree, like we do with PCRE.
"native" ZLIB support, without the need of any dynamic
libs, would be great.

Brgds,
Viktor

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to