Ant

Development
21

Thus spake viewofheaven:

I agree with Brent. If anyone needs this (build with ant), let me know,
and I’ll translate the Makefile into an ant config. I will also hope to
have Joel’s feedback on this, so that we can put the ant file into SVN.

We used to have an ant script, which was used for building releases
prior to 3.0. When I started doing release builds, I tried to update the
ant script. I found that things which were trivial to do in a Makefile
were not easily achieved with ant, and the verbosity of XML made it hard
to see what parts of the script did. As a result, I stopped maintaining
the ant script, and eventually removed it from the SVN repository.

My current feeling about ant is that it’s an inelegant, difficult-to-use
solution to a problem that make solved 30 years ago. If you find it
worthwhile to create an ant script for your own use, you’re welcome to
do so, but I won’t be using ant for building releases.

–
J.

22

Thus spake pgeerkens:

Anybody into sidebets? My money is on > 2 years for VASSAL 4, though
Joel claims < 2 months. :slight_smile:
(The exact claim was “by Christmas”, as I recall, though I do not
actually recall a year being specified. Shades of 1914!)

When I made that prediction, I thought we’d have a beta for 3.2 released
by now. The clock’s not ticking on V4 development yet.

–
J.

23

I think I’ll just write an elegant howto for building Vassal using your Makefile within Cygwin. Cygwin is easily installed and uninstalled, and the average user (following my howto) won’t be digging in too deep with daemons and all.

Cygwin installation is clean and innocent (without daemons).

Will be good to get budding developers on Cygwin (within 5 minutes of installing) in preparation for Vassal 4 anyway.

But 1 thing might make this all moot (about letting users build easily). How do you manage to rebuild for almost every other commit your developers make? Still, if it’s good housekeeping that we can use, I’ll do it.

24

Hi all. Joel’s prediction isn’t wrong.

IMHO, we would want Vassal to continue running, so incremental updates is the way to go. I suggested tying Qt to Vassal’s Java (Qt Jambi). Or wxWidgets, wx4j (a very thin wrapper over wxWidgets, apparently).

In any case, with proper abstraction, retrofitting Vassal’s Java will definitely let us overcome any graphics problems quickly (1-2 weeks of rewriting ScaledImagePainter).

The wx4j project stopped activity in 2004, but that’s likely because it is merely a thin wrapper and is more than robust for its purpose.

Qt Jambi is stable at v4.6.3 on Aug 2010.

Qt or wxWidgets, your call. As I said, with proper abstraction, we can switch to any toolkit at a whim.

As long as we deal in OO layers (abstractions), I don’t see how we need to dismantle all of Vassal to port to any language (especially C++).

Joel’s estimate is correct: 2 months. But the countdown doesn’t start now. It starts with getting Vassal 3.2 fully integrated with target GUI toolkits. The Vassal Engine itself can easily be translated to C++, even for complex stuff like multithreading (say with Boost). (Is there even multithreaded stuff in Vassal now? But we sure need them moving forward.)

Besides, any port that takes longer than 2 months is of dubious benefit. Vassal isn’t exactly coded in an ancient language and drowning in tons of spaghetti code. It’s neat enough not to require a 360-degree overhaul. (So, everybody please chip in and continue our peer-review efforts for codes! :slight_smile:)

What was the original problem with Java? Graphics? What say we start by weaving Qt or wxWidgets into Vassal 3.2? Currently, with my level of use of Vassal, I haven’t even hit that graphics problem yet.

IMHO, I would like a powerful Java-based Vassal, not a wimpy C+±based Vassal. Version numbers notwithstanding.