Hi Viktor

First of all, I support your decision, don't get me wrong. Maybe this
statement be unnecessary.

I can (guessing) understand what Massimo said. Some modern
languages/development platforms allow this construction in a portable way
(Java, CLR, Python, Ruby, even Delphi could), some better than others on
results and implementations. It demands a deploy on
development environment to generate information about external libs
(probably generating some like a more complex .hbc) and It isn't just a
compiler directive. Ok, is a little bit different, but I think it is, in
general, what Massimo wants. It has ways to implement this in a good way.
Maybe not be ease or even compensate to implement it, but it's possible.
Certain it requires lots of work.

IMHO, in general I think this is *a little* better and ease to Harbour users
than build options although it isn't so ease to Harbour developers to
implement it. The question is:

Is it good to Harbour philosophy? I guess it is not.

Personally if I am the last Harbour user I would drop total portability and
compatibility with the past, specially I would drop multiple compilers and
dead platforms. A software without maintenance for 2 years is dead. Users
have the right to continue using these zombies, people are still using
Clipper :-). Harbour support this and it's ok. I completely understand
Harbour's DNA and I will support it until the almost 100% of community
decides to change this.

Portability is a solution so as a problem too :-)

Setting dependencies in hbc and hbp files is more simple and good enough,
sure, but I just don't think it's a ton better than a good lib import
implementation in compiler, even considering portability. Anyway I think
Harbour has others priorities to be a better development platform that that.

I see the problem in a different way but in final I am just confirming your
words.

[]'s Maniero


F.e. please explain how will harbour compiler
> find the headers of your dependency? Also think
> about how the possible dependencies of your
> dependency will be added to the build?
>
> You could also explain, why adding 'mypkg.hbc'
> to the build cmdline is worse than adding
> '#pragma "mypkglib1.lib"' to each source
> that might use that package?
>
> What happens if one dependency consists of
> multiple libs? Should the user remember to
> list each of them in each source? What happens
> if the lib packager decides to change the
> internal layout or names of the libs? Will
> you want to go through all source files and
> change it each time? How will
> "#pragma "mylib.lib" be portable between
> compilers? Should the compiler know about
> the different lib naming schemes of all the
> compilers we support?
>
> Anyhow I think the first thing you should do
> before for yet another feature, is to look at
> the problem as a whole and decide what is the
> issue you _really_ want to solve here, and
> check whether there exist a solution for it
> already.
>
> Having features and hacks just to have them,
> or without good reason is not something we
> welcome in Harbour.
>
> IMO .hbc files are just a ton better to
> solve this problem, and portable. Try it.
>
>
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to