Hi, > 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.
I know how it's used in these language, but this doesn't really help us finding the exact way to implement this in Harbour. It has lots of components, and we have several parts to deal with, plus we have our own "coordinate system", goals and even heritage where this thing should be solved. If someone doesn't understand it, it's a pity. Asking for more is nice, but repeating the same request like a parrot isn't. Sorry, but I find it a huge waste of time to write anything here, when it's ignored. If someone writes a request/question but doesn't read the answer, or isn't bothered to look up past discussion (or read INSTALL for that matter), I'm pretty sure it's not important enough to waste _more_ time on it. > 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 Harbour's major point is being portable. If we ought to support more than one operation system, we will _have to_ support multiple compilers, too (and no, gcc isn't exactly the same on all platforms, nor is it available on all platforms). We can (and we used to) drop compilers which are definitely dead, but it's not so easy, f.e. lots of ppl are still using BCC55, even though it's not developed since 10 years. So we do this, but it doesn't solve the problem, since usually we have more than 1 living compiler to support. And this is actually a quite huge advantage, since we're not stuck into one option. Even having 1 supported compiler isn't a solution, since if this becomes dead, we need to port to another one, which may or may not support actual favorite (non-standard, non-ANSI C, compiler specific) feature. And what is forgotten many times: Harbour as a language isn't by definition tied to a C compiler. So far it was, but as a future development path we keep the possibility to completely drop it. Pls keep that in mind when thinking about any solution. > Portability is a solution so as a problem too :-) Yes. > 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. Exactly. Such feature would require total integration of build tool and compiler (hbmk2 and harbour). Meaning harbour compiler will in essence be dropped and all work would be done in hbmk2, which in turn gets much more intimate information from source parser (compiler) than now, most importantly embedded references of package names, and compiler would have to deal with .hbc parsing and automatic inclusion of referenced #include files, etc. It's essentially an "#package "mypkg[.hbc]" feature. Plus some sort of .hbc repository has to be solved. Looks like a lot of work to me and a lot of potential discussion along the way. It would also require that user understand and accept the .hbc concept, since it will be something similar to the one we have already. BTW, if someone really wants to use the half-baked solution, we have #pragma BEGINDUMP/ENDDUMP since many years, which makes everyone free to use any sort of weird and C compiler dependent code embedded in .prg, including '#pragma lib', and whatever else that seems to be useful. I don't recommend it, but it works regardless. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
