and more thing: What about Cygwin? It seems it doesn't work currently (hbtest fails instantly).
Delete or fix? Brgds, Viktor On Thu, Mar 5, 2009 at 4:56 PM, Viktor Szakáts <[email protected]> wrote: > 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
