You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/05/12 19:53:54 UTC
Win32 build schema
At 12:19 PM 5/12/2005, Curt Arnold wrote:
>On the build specification, the VS IDE project files are helpful for
>debugging but they are awkward to set up and don't run unit tests,
>assemble distributions, etc. To use APR within log4cxx, I've created
>Ant scripts to build APR and log4cxx which work with a large variety
>of compilers. Since I'm just building APR static libraries to use in
>linking log4cxx, I'm wasn't terribly concerned with precisely
>mimicking the settings in the VS6 project files. The ant script can
>produce VS6 project files to give users a quick way to set up a
>debugging environment, but they aren't the definitive build environment.
Of course, they could.
>That approach works well for me, but the reason that I bring it up is
>that it suggests that providing a MSBuild script and a VC6 IDE
>project (ideally derived from the MSBuild script) might be the
>desirable combination. MSBuild scripts are likely to be a lot
>cleaner than the VC6 project, able to drive the unit tests, can be
>read by VS.NET 2005 to provide a development and debugging
>environment. If MSBuild drives the compilers via the command line,
>it is likely to be able to be paired with earlier Microsoft
>compilers. Since it will be distributed as part of the .NET
>framework, it can still be used by developers who do not have VS.NET
>2005.
>
>I'd like to pass on that I have observed that some unit tests fail in
>the Windows build when I run them from my Ant script. Since I have
>seen no other way to run them on that platform, I can't confirm if
>they are bugs in the Windows implementation of either the tests or
>the code under test or bugs in the build process. I think it is
>possible that the unit tests have gotten stale on the Windows
>platform since they aren't readily run and an MSBuild script would
>address that issue.
I believe the issue can be summed up as;
* we need a ./configure.bat which can produce structure in:
* .sln/.vcproj for VS 7+
* .dsp/.dsw for VS 6-
* makefile for nmake/gmake
* build.xml for ant
* MSBuild script
Oh - let's not forget (and each of these requires someone who cares
enough to write the per-project-format module)...
* Apple's Project IDE
* assorted unix IDEs
* CodeWarrior
* butter ;-)
So we need to choose a language just to create these files. What
do we trust? I insist we be able to execute it on unix in order
for anyone to package win32 builds. One main app, one per-project
template module (e.g. apr, libapr apr-util etc) and a module-per-
environment which can stuff up the file.
What are the per-project templates? If they came [mostly] from
the unix build schema, we would be in hog heaven.
Perl and java are installed most everywhere, python is catching up,
.NET is here on modern Windows boxes but most unix boxes don't have
mono installed. I'd like this to be painless as possible.
Bill
Re: Win32 build schema
Posted by Curt Arnold <ca...@apache.org>.
On May 12, 2005, at 12:53 PM, William A. Rowe, Jr. wrote:
> At 12:19 PM 5/12/2005, Curt Arnold wrote:
>
>> On the build specification, the VS IDE project files are helpful for
>> debugging but they are awkward to set up and don't run unit tests,
>> assemble distributions, etc. To use APR within log4cxx, I've created
>> Ant scripts to build APR and log4cxx which work with a large variety
>> of compilers. Since I'm just building APR static libraries to use in
>> linking log4cxx, I'm wasn't terribly concerned with precisely
>> mimicking the settings in the VS6 project files. The ant script can
>> produce VS6 project files to give users a quick way to set up a
>> debugging environment, but they aren't the definitive build
>> environment.
>>
>
> Of course, they could.
>
Sorry, I was saying that the VC6 IDE was definitive with log4cxx.
The Ant build are.
>
>> That approach works well for me, but the reason that I bring it up is
>> that it suggests that providing a MSBuild script and a VC6 IDE
>> project (ideally derived from the MSBuild script) might be the
>> desirable combination. MSBuild scripts are likely to be a lot
>> cleaner than the VC6 project, able to drive the unit tests, can be
>> read by VS.NET 2005 to provide a development and debugging
>> environment. If MSBuild drives the compilers via the command line,
>> it is likely to be able to be paired with earlier Microsoft
>> compilers. Since it will be distributed as part of the .NET
>> framework, it can still be used by developers who do not have VS.NET
>> 2005.
>>
>> I'd like to pass on that I have observed that some unit tests fail in
>> the Windows build when I run them from my Ant script. Since I have
>> seen no other way to run them on that platform, I can't confirm if
>> they are bugs in the Windows implementation of either the tests or
>> the code under test or bugs in the build process. I think it is
>> possible that the unit tests have gotten stale on the Windows
>> platform since they aren't readily run and an MSBuild script would
>> address that issue.
>>
>
> I believe the issue can be summed up as;
>
> * we need a ./configure.bat which can produce structure in:
>
> * .sln/.vcproj for VS 7+
> * .dsp/.dsw for VS 6-
> * makefile for nmake/gmake
> * build.xml for ant
> * MSBuild script
>
> Oh - let's not forget (and each of these requires someone who cares
> enough to write the per-project-format module)...
>
> * Apple's Project IDE
> * assorted unix IDEs
> * CodeWarrior
> * butter ;-)
The cpptasks tasks for Ant (http://ant-contrib.sourceforge.net/
cc.html) does a decent job generating VC 5, 6 and CBuilderX/gcc
project files, attempts VC7, XCode and CBuilderX/bcc. Instead of
creating something new, I'd polish the Ant script that I'm using in
log4cxx and add any necessary project generating classes.
>
> So we need to choose a language just to create these files. What
> do we trust? I insist we be able to execute it on unix in order
> for anyone to package win32 builds. One main app, one per-project
> template module (e.g. apr, libapr apr-util etc) and a module-per-
> environment which can stuff up the file.
>
> What are the per-project templates? If they came [mostly] from
> the unix build schema, we would be in hog heaven.
>
> Perl and java are installed most everywhere, python is catching up,
> .NET is here on modern Windows boxes but most unix boxes don't have
> mono installed. I'd like this to be painless as possible.
>
Please review the Ant scripts that I'm using in log4cxx. The INSTALL
file in the CVS HEAD of logging-log4cxx should tell you how to get
set up. Do not use Ant 1.6.3 as it has problems that broke cpptasks
and Clover. The CVS HEAD of Ant or 1.6.2 should work fine.
RE: Win32 build schema
Posted by Dan Johnson <dm...@nrtc.northrop.com>.
I'm new to the list so apologies in advance if you've already seen it,
but take a look at http://www.ociweb.com/product/mpc/. It's Perl,
supports GNU Make, NMake, Visual C++ 6, 7.1 & 8, Embedded C++, &
BorlandMake and is available under YAAHOSL (Yet Another Ad Hoc Open
Source License). It was developed to coordinate the build process for
ACE so it's definitely industrial strength.
Dan
Daniel M. Johnson Software Engineer | One Hornet Way, MS 9M52/W6
Northrop Grumman Integrated Systems | El Segundo, CA 90245-2804
J-UCAS Vehicle Management Systems | Telephone: (310) 345-5253
-----Original Message-----
From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
Sent: Thursday, May 12, 2005 11:06 AM
To: William A. Rowe, Jr.
Cc: Curt Arnold; APR Developer List
Subject: Re: Win32 build schema
William A. Rowe, Jr. wrote:
> So we need to choose a language just to create these files. What
> do we trust? I insist we be able to execute it on unix in order
> for anyone to package win32 builds. One main app, one per-project
> template module (e.g. apr, libapr apr-util etc) and a module-per-
> environment which can stuff up the file.
>
> What are the per-project templates? If they came [mostly] from
> the unix build schema, we would be in hog heaven.
>
> Perl and java are installed most everywhere, python is catching up,
> .NET is here on modern Windows boxes but most unix boxes don't have
> mono installed. I'd like this to be painless as possible.
A while back I had posted the beginnings of a patch to gen_make.py that
used ezt.py to templatize the existing win32 build system, making it
automatically generated. This could easily be extended to generate
other types of build files, if someone was motivated enough to continue
the work. I never did because I don't actually have access to a win32
system to test things on, and none of the win32 developers ever got back
to me with confirmation on whether things worked or not.
Note that this is how Subversion's win32 build works, and it allows us
to build with various different versions of visual studio just fine.
-garrett
Re: Win32 build schema
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:05 PM 5/12/2005, Garrett Rooney wrote:
>A while back I had posted the beginnings of a patch to gen_make.py that used ezt.py to templatize the existing win32 build system, making it automatically generated. This could easily be extended to generate other types of build files, if someone was motivated enough to continue the work.
Lets sandbox this and get some code committed, so we can start
the effort to put something together.
I'll lead in my free time (sparse now, but opening up shortly.)
Bill
Re: Win32 build schema
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
William A. Rowe, Jr. wrote:
> So we need to choose a language just to create these files. What
> do we trust? I insist we be able to execute it on unix in order
> for anyone to package win32 builds. One main app, one per-project
> template module (e.g. apr, libapr apr-util etc) and a module-per-
> environment which can stuff up the file.
>
> What are the per-project templates? If they came [mostly] from
> the unix build schema, we would be in hog heaven.
>
> Perl and java are installed most everywhere, python is catching up,
> .NET is here on modern Windows boxes but most unix boxes don't have
> mono installed. I'd like this to be painless as possible.
A while back I had posted the beginnings of a patch to gen_make.py that
used ezt.py to templatize the existing win32 build system, making it
automatically generated. This could easily be extended to generate
other types of build files, if someone was motivated enough to continue
the work. I never did because I don't actually have access to a win32
system to test things on, and none of the win32 developers ever got back
to me with confirmation on whether things worked or not.
Note that this is how Subversion's win32 build works, and it allows us
to build with various different versions of visual studio just fine.
-garrett