Return-Path: 
 <axis-dev-return-22905-apmail-ws-axis-dev-archive=ws.apache.org@ws.apache.org>
Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org
Received: (qmail 27514 invoked by uid 500); 1 Aug 2003 10:08:30 -0000
Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
list-help: <mailto:axis-dev-help@ws.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@ws.apache.org>
list-post: <mailto:axis-dev@ws.apache.org>
Delivered-To: mailing list axis-dev@ws.apache.org
Received: (qmail 27470 invoked from network); 1 Aug 2003 10:08:30 -0000
Message-ID: <00e201c35814$e00e9c70$d0f62509@lankabook2>
From: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
To: <axis-dev@ws.apache.org>
References: <40F39C234319D611BCCB00B0D0D1CB332A415B@ENETSLMAILI>
 <3F29419B.5020403@iseran.com>
Subject: Re: C++ commits
Date: Fri, 1 Aug 2003 16:08:11 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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" <steve_l@iseran.com>
To: <axis-dev@ws.apache.org>
Sent: Thursday, July 31, 2003 10:19 PM
Subject: Re: C++ commits


> Lilantha Darshana wrote:
> > Steve Loughran wrote:
> >
> >>
> >>damitha@opensource.lk 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.
>