Thanks for your comments. It's not just hbmk2. The real problem is that each of these compilers need to be tested, documented, builds done, waiting for green lights, spending time of workarounds... with no real value. We have limited time, and there are much more important areas to spend it on. We have quite many compilers so adding a few buggy ones really doesn't enhance our code quality to a great deal, on the contrary it just makes it more complicated.
Let's leave XCC, if you need it for testing. Specifically for DMC, I think it added no value since adding it last year, but I've alone spent a few days on it so far. I'm half way into deleting it, but I can start over if you need this compiler, just send me a short confirmation please. As for moving the logic inside hbmk2 to external templates, it would surely be nice, but I envision it as a huge amount of work, it needs to be designed well, flexible, yet comprehensible. We will see, first I'd like to wait until we finish and test internal support for the full line of our compilers. If this is done, it's much easier/safer to compose a picture about a fitting template system. Brgds, Viktor On Thu, Mar 5, 2009 at 4:44 PM, Przemyslaw Czerpak <[email protected]>wrote: > On Thu, 05 Mar 2009, [email protected] wrote: > > Hi, > > > ; NOTE: More candidates for such pruning are: > > - dmc (buggy and compiler not updated) > > - xcc (based on very old version of pocc) > > Any opinions? > > XCC is native xHarbour.com compiler. I do not use it but from time > to time I have to make some tests with this compiler, f.e. to check > if sth is a compiler problem or bug in the code. I do not use xHarbour > so support for XCC is very usable for me. > DMC has a know bug in INT64 integers but it can be defined on the same > level as some PellesC problems. Just simply here I was not interested > in looking for workaround. I do not think we should remove it. > Current SVN code needs some cleanups for DMC builds but it seems to be > rather easy job. > Of course I understand that support for large set of C compilers in > hbmk2 is problematic and you do not want to add all possible compilers. > It's reasonable for me. We do not have to support in hbmk2 all exotic > C compilers people may want to use. > Anyhow I think that in the future we should think about defining support > for new C compiler only in hbmk.cfg. Of course it may not be easy but such > functionality can greatly help when Harbour is ported to new platform. > F.e. I will add support for SunOS and native C compiler. It will be nice > if I can also add support for this compiler without touching hbmk2.prg > code but only adding some definitions to hbmk.cfg in postinst.sh. > Probably in similar way to defining cross build environment. > Please think about it. It's not urgent. IMHO it's even better to well > test current hbmk2 in different environments to catch some missing > functionality before we define some universal rules for all compilers. > > best regards, > Przemek > _______________________________________________ > 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
