🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Ant (and automated build tools)
Author
So I'm performing a big internet no-no and cross-posting from the Ant users mailing list because I'm an impatient bastard, and because I think someone here might have a better solution:
Actually, before the cross post, my goal is an automated build system to check compile status after svn commits, and my project uses DirectX and DXUT (so an older version of the sdk isn't an option). If anyone has a working solution for this on a linux server, for the love of god please tell me. Anyways, here's the post:
I'm in a kind of messed up development environment, so before my
question I'm going to provide a little background:
My project depends on (among other things) DirectX and DXUT to build (C++).
My server is running linux, and it's not really an option to switch
over to windows.
My goal is a cross-compile environment on the server to check svn
commits (I'm planning to use CruiseControl).
I went pretty far setting up a cross-dev environemtn using mingw32,
and of course ran into trouble when I needed to compile against
DirectX. It seems mingw doesn't like the DX headers, and also may or
may not have trouble with unicode projects (which DXUT requires). So,
long story short I dropped mingw and decided to use MSVC which runs
pretty damn well under wine.
I'm using the cpptasks plugin, or taskdef, or whatever they're called
(sorry, I'm brand new to ant), and a shell script to call msvc through
wine, which is working pretty well.
My (hopefully) last problem now is this: In the fileset to grab all
the .cpp files it takes all the relative search paths I set and makes
them absolute paths, so "**/*.cpp" turns into, for example,
/var/cruisecontrol/checkout/idkfa/src/messaging/eventmanager.cpp .
What's wrong with that? Well, since this gets passed to cl (the MSVC
command-line compiler), and since most windows apps (cl included) use
/ for command-line flags instead of - it tries to interpret every
single file as some command-line parameter instead of a file:
[cpptasks:cc] cl : Command line warning D9002 : ignoring unknown
option '/var/cruisecontrol/checkout/idkfa/libs/include/DXUT.cpp'
SO, finally, my question: Is there any way to force the fileset
returned values to be relative paths? Or is there any way I can modify
what it returns, through a find-replace or some kind of tool?
Of course, if anyone has a better build automation solution for me I
would absolutely love to hear it since this seems hack-a-licious and
prone to failure to me.
Thank you!
I tried using Ant with cpptasks to build my C++ project on both Windows using MSVC and on Linux, with the goal being to have one wonderful build script that whatever platform could run and produce the same output. I quickly found that I was being unrealistic and that actually the build script requires an awful lot of hacky logic to get to work cross-platform. Of course XML doesn't represent logic all too prettily and I eventually dropped Ant in favour of platform-specific build scripts. It's not as pleasing having a separate 'Windows' and 'Linux' script, but it's the same amount of work and is less hacky.
Another problem I had with cpptasks is that some poorly configured projects can take infinite time to build (seemingly only on Windows), which I found out when I tried building with one such external project. There is a fix, in the form of an unintegrated patch from half a decade ago. That should set alarm bells ringing.
It's not important but actually I'm still using Ant on Linux, but only for Linux - it may as well be Make or SCons or whatever. I just couldn't be bothered to re-implement it and instead stripped out logic that dealt with Windows and MSVC.
I know that doesn't answer your question but hopefully it'll help in that it will make you consider a build script per platform instead of 'the one and only build script' that Ant fails to deliver! If you were to make a script per platform you'd be able to solve this problem much more easily, methinks.
Another problem I had with cpptasks is that some poorly configured projects can take infinite time to build (seemingly only on Windows), which I found out when I tried building with one such external project. There is a fix, in the form of an unintegrated patch from half a decade ago. That should set alarm bells ringing.
It's not important but actually I'm still using Ant on Linux, but only for Linux - it may as well be Make or SCons or whatever. I just couldn't be bothered to re-implement it and instead stripped out logic that dealt with Windows and MSVC.
I know that doesn't answer your question but hopefully it'll help in that it will make you consider a build script per platform instead of 'the one and only build script' that Ant fails to deliver! If you were to make a script per platform you'd be able to solve this problem much more easily, methinks.
Author
thanks for the response... but i guess i wasn't all that clear.
The only reason I'm using Ant is because the automated build tool (CruiseControl) uses it, and therefore I have to use it for the automated build process.
When the devs are working on the actual project they are all windows-only and so use the visual studio solution.
If there's any alternative to cruisecontrol/ant that knows how to sync with svn to do a test compile after a commit, and preferably has integration with the Trac system, then I'd be more than happy to use it.
The only reason I'm using Ant is because the automated build tool (CruiseControl) uses it, and therefore I have to use it for the automated build process.
When the devs are working on the actual project they are all windows-only and so use the visual studio solution.
If there's any alternative to cruisecontrol/ant that knows how to sync with svn to do a test compile after a commit, and preferably has integration with the Trac system, then I'd be more than happy to use it.
That's strange, I'd expect most continuous integration systems to allow you to build the project however you want rather than forcing Ant or any other build system on you! If you eventually decide on Cruise Control for certain, you could use Ant to just call whatever build system suits your needs, it has tasks available for doing that.
I'm using Pulse by Zutubi for my project, and I think it's the bee's knees. I happen to have it hooked up to Ant for building, but it will work with whatever command or tool you choose. It has support for Ant and quite a few other common systems (support meaning it will parse the output and give you some meaningful reports based on that), and is easily extensible to parse the output of whatever other tool you may want to choose.
Unfortunately it's only free for a one-server, one-man team, effectively as an evaluation, but frankly if I was developing a serious project I hoped to make money from, I'd pay for it.
Also I should mention the customer support is brilliant and the developers respond to any problems very quickly and helpfully.
Hope that helps!
I'm using Pulse by Zutubi for my project, and I think it's the bee's knees. I happen to have it hooked up to Ant for building, but it will work with whatever command or tool you choose. It has support for Ant and quite a few other common systems (support meaning it will parse the output and give you some meaningful reports based on that), and is easily extensible to parse the output of whatever other tool you may want to choose.
Unfortunately it's only free for a one-server, one-man team, effectively as an evaluation, but frankly if I was developing a serious project I hoped to make money from, I'd pay for it.
Also I should mention the customer support is brilliant and the developers respond to any problems very quickly and helpfully.
Hope that helps!
Hi, I have succesfully set up a cruise control + make on linux with target to have a cross platform continuous intergation. The key idea is that ant allow to exec any command : so I make it call 'make' :) It seems that the native cpp Ant support is still not good compared to other build system.
There is also a way to make cruise control build a visual studio solution
Furthermore, regarding the cross platform build, I use autotools and msys+migwin on windows, compiling with the same makefiles on both linux and windows. It seems to me that autotools is one of the best way to have a fully cross platform build system (I still have to try it on mac os)
My plan is to virtualize building platforms and control the continuous intergration through cruise control. Latest VmWare workstation (6.5 beta) has a directx9 support for virtualized windows, which is cool. It allow me to run the automatic testing inside the vitrualized windows (some require to launch an Ogre window...). It also provide an opengl 1.4 to a virtualized debian, which is cool too.
I quickly abandonned cross compiling idea because of some bugs from mingw (like seg fault when throwing an exception from a dll catched in another) but I do not know if the status has changed.
As a final word, it seems to me that the virtualisation solution has several advantages comparing to the wine/emulation solution : more platforms can be taken into account, build and test can run silently on my desktop, and I hope it will produce "cleaner" exe.
I think a solution to your problem could be :
* YourLinuxServer(VMware(Windows(cruise control --> Ant --> visual studio)))
* or event : YourLinuxServer(cruise control --> Ant -run-> VMWare(Windows(build.bat -> visual studio)))
Regards
[Edited by - rogma on September 12, 2008 3:07:18 AM]
There is also a way to make cruise control build a visual studio solution
Furthermore, regarding the cross platform build, I use autotools and msys+migwin on windows, compiling with the same makefiles on both linux and windows. It seems to me that autotools is one of the best way to have a fully cross platform build system (I still have to try it on mac os)
My plan is to virtualize building platforms and control the continuous intergration through cruise control. Latest VmWare workstation (6.5 beta) has a directx9 support for virtualized windows, which is cool. It allow me to run the automatic testing inside the vitrualized windows (some require to launch an Ogre window...). It also provide an opengl 1.4 to a virtualized debian, which is cool too.
I quickly abandonned cross compiling idea because of some bugs from mingw (like seg fault when throwing an exception from a dll catched in another) but I do not know if the status has changed.
As a final word, it seems to me that the virtualisation solution has several advantages comparing to the wine/emulation solution : more platforms can be taken into account, build and test can run silently on my desktop, and I hope it will produce "cleaner" exe.
I think a solution to your problem could be :
* YourLinuxServer(VMware(Windows(cruise control --> Ant --> visual studio)))
* or event : YourLinuxServer(cruise control --> Ant -run-> VMWare(Windows(build.bat -> visual studio)))
Regards
[Edited by - rogma on September 12, 2008 3:07:18 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
