axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: C++ commits
Date Thu, 31 Jul 2003 16:19:39 GMT
Lilantha Darshana wrote:
> Steve Loughran wrote:
>> 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

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!
> 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.

View raw message