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
