Yes, it's a problem, particularly when a lib is binary only. The most affected platform is Windows, where there are plenty of compilers with multiple CPUs, Unicode/non-Unicode, C/C++ mode, plus - thank god... - WinCE.
Part of my effort is to find the "best" C compiler for Harbour. We've started from BCC, I went to MSVC, but since last week I think the strongest contender is MinGW. Now it seems practically on par with MSVC regarding execution speed and target CPUs. Its only downside is compiling speed and slower linker. Even with these, I think we can easily make it the "default" compiler (if that's what you meant) for Harbour on Windows. MSVC could be the secondary compiler, because it has very good support. With these two, 99.9% of professional needs is covered. IMO we should go into this direction. [ let me note that it's already a huge achievement that it's now so easy to switch between these compilers. ] And it's not only the C compiler, it's also the build tool (for source distributed libs). GNU Make is good, but GNU Make is not the friendliest tool on earth. Brgds, Viktor On Thu, Mar 26, 2009 at 2:42 AM, Phil Barnett <[email protected]> wrote: > Viktor Szakáts wrote: > >> 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. >> > > And that is where we depart in general from what made Clipper the 3rd party > success it was. Those third parties could distribute a library. Maybe two. > We can't deal easily with precompiled code (libraries or objects) unless > those same third parties distribute those libraries for multiple platforms > and even perhaps multiple compilers. This raises the bar significantly for > entry to the third party banquet. Our original goal was multiple compilers > and multiple platforms. That has been accomplished, but in this respect, > it's our Achilles heel. And, worst of all, we don't have 'the most popular > compiler around', which is what made third party developers desire to put in > the work. I'm not saying what we have is bad in any way. it's not. Harbour > is vastly superior to Clipper. > > At the very least, we would need to maintain a published list of compiler > and target platforms so the large yet finite list is well known. That would > at least give a third party developer a target, even if it is a huge one. I > think it's a rather large problem. > > This was perhaps the least understood trade off that we made with our > multiplatform multicompiler goal. Our goal was not bad, but look what came > with it. > > I don't have the answer, just more things to ponder and some realities to > accept. > > _______________________________________________ > Harbour mailing list > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour >
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
