Hi Chen and All,
One more thought to your e-mail.
Integration of 3rd party *Harbour* libs into Harbour SVN, while this is
off-topic regarding my first mail, and while I don't think the situation is
that
bad, because we've only added hbsqlit3 as a formerly existing independent
3rd party lib to our SVN, I do see what you mean and you're right. It would
indeed be better to leave many libs to live independently.
There are a few issue with Harbour 3rd party libs in general
(talking about open source ones for now):
1) Each has a different make system, which means each of them has
to be learned, built and locally maintained in a completely different
way.
2) These make systems and libs are often targeting only a small subset
of supported Harbour platforms.
With 2) we cannot really do anything besides providing all portable APIs
we have, and programming methods and every other rules we use throughout
Harbour development.
I wonder however, how could we help 3rd parties with 1), namely to give
them a good make system infrastructure.
For small projects hbmk2 can be an answer, but for larger ones, this isn't
enough, so either we should extend it, or think about applying our GNU
Make infrastructure to other projects. For the latter, maybe the easiest
way is our current HB_CONTRIB_ADDON method. With this, 3rd party
libs are expected to have one 'Makefile', copying their sources to contrib
and passing the dir name to HB_CONTRIB_ADDON envvar to get them
built, just like our regular "built-in" contribs.
Maybe, it would be better to provide and 'addon' dir for this purpose.
Again, more ideas are welcome. It would be nice to help other lib
developers, so that they don't have to reinvent the wheel make-system-wise,
and to provide Harbour users a easy to manage environment.
[[ I know this is just one side of 3rd party lib development. ]]
Brgds,
Viktor
On Tue, Mar 24, 2009 at 7:58 AM, Chen Kedem <n...@synel.co.il> wrote:
> Viktor,
>
> > I'd welcome opinions from everyone.
>
> Personally I don't think we should add every 3rd party library in the
> market to the
> Harbour repository. There are endless features out there that are "nice to
> have",
> but not every such tool need to have wrapper functions in this project.
>
> Look at the size of "core" tree compare with the size and number of files
> in "contrib".
>
> The great part of Clipper was the fact that the basic complier had a huge
> 3rd party
> companion market (both free and commercial). It was not integrated into one
> monolithic product.
>
> 3rd party wrote libraries that worked with that compiler and default
> libraries
> (plus the C-RTL).
>
> Now, in Harbour, instead of the people that write the libraries try to
> adopt their
> product to Harbour. The Harbour developers "hunt" for external projects and
> do
> the adaption here (as the original lib team might not had even heard about
> Harbour).
> I don't think this is good.
>
> I know these tools are useful, but the scope is just too huge. And now you
> propose
> to add even tighter integration which will force part of Harbour to be
> updated every
> time an external library is being updated. Well, it looks like endless
> task.
>
> BUT: As YOU are the one doing most (or all) the cleaning, and if you think
> this is
> not a nightmare, and will even cause you less work in the future, go for
> it.
>
>
> Chen.
> _______________________________________________
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
