Hi agree about importance of give a choice and agree mingw/msvc path can we follow Minigui that include harbour & MinGW to be ready to use for windows platform? it can be a strong messages for third parties libraries we can cooperate (divide effort) with minigui project and distribute/promote any library-tool for standard hbwin format based mingw&msvc
2009/3/26 Viktor Szakáts <harbour...@syenar.hu>: > 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 <ph...@philb.us> 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 >> 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 > > -- Massimo Belgrano _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
