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.
