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
