Then we'll have both in place and let user decide which one to use, and that helps us on nightly gump builds etc. as well.
-Lilantha -----Original Message----- From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 4:08 PM To: [EMAIL PROTECTED] Subject: Re: C++ commits Can these not co-exist? I mean, can we not have auto-conf'ed makefiles and ant files .. let the user decide. "Can't we all just get along?" Sanjiva. ----- Original Message ----- From: "Steve Loughran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 31, 2003 10:19 PM Subject: Re: C++ commits > Lilantha Darshana wrote: > > Steve Loughran wrote: > > > >> > >>[EMAIL PROTECTED] wrote: > >> > >> > >> > >>>>On Fri, 25 Jul 2003 10:02:56 -0700, Steve Loughran wrote > >>> > >>> > >>> > >>>> <cc debug="${build.debug}" > >>>> outtype="executable" > >>>> objdir="${obj.dir}" > >>>> multithreaded="true" > >>>> incremental="true" > >>>> exceptions="true" > >>>> > >>>> runtime="static" > >>>> > >>>> subsystem="gui" > >>>> > > >>>> <defineset refid="core-defines"/> > >>>> <compiler refid="studio" > > >>>> <precompile prototype="${stdafx.cpp}"/> > >>>> </compiler> > >>>> <!-- C++ source --> > >>>> <fileset dir="${src.dir}" > >>>> includes="*.cpp"/> > >>>> <includepath location="${IDL.dist.dir}" /> > >>>> </cc> > >>>> > >>>The above ant build seems very attractive. > >>>In Microsoft compiler cl, options for multithreading is /ML and for > > > > exceptions > > > >>>/GX. But how does the above multithreaded="true" and exceptions="true" > > > > map to > > > >>>the VC compiler options? > > > > > >>Magic. Or more likely the per-compiler adapter classes in the JAR. > > > > > >>TW, there is >1 exception option in MSVC, such as /EHsc and /EHa ... I > >>ont know which one they use > > > > > > > > mmm.., what if these adapters are not defined for a given compiler??? > > For an example for Watcom C++ compiler! this is not gonna work, right. > > see http://ant-contrib.sourceforge.net/cc.html > > no, you have to write a new one. > > > > > I guess <cc> task is still in its 0.3 Alpha version. So, probably we > > may end up with fixing bugs in that, without building the C++ project. > > (may be I'm wrong) > > It is pretty stable. We are using it here for soon-to-ship Win32 product > and handing it MIDL compile, C++ compile, RC compile and linking. > > > > But if you use automake, autoconf etc. The configuration script does > > the job for you! on Unix platforms, it looks for an existing compiler > > in the platform and further even it looks for library compatibility, > > include file compatibility, versions & so on.... and it creates Makefiles, > > config.h etc, based on these conditions. So using autotool on Unix is > > preferable until a stable Ant version is provided for <cc> task > > Like I said, it is pretty stable. > > > see for an example how xerces-c is building on Unix! > > http://xml.apache.org/xerces-c/build-winunix.html#UNIX > > > > Hence, I prefer makefiles rather than Ant <cc> task for C++ projects, > > until Ant is capable of handling all of the things that autotools can. > > > > And we can use compiler IDE specific project files to build for > > Win32 etc. (like MSVC project file *.dsp or you can use nmake for VC etc) > > your choice. But you lose the ability to have nightly gump builds, > cruise control and all the test and deploy features we are used to in > java-land. And on windows you have the issue of VCC project versions. >
