This page contains information (both frequently asked and just stuff we think you ought to know) about the source release of Pueblo/UE. If you're not interested in using the source code, and only want to use the precompiled program, then don't worry about anything on this page and just go back to the product page.

Stuff you'll need

• A CVS client, and knowledge of how to use it (optional, but recommended).
• Borland C++'s Free Compiler or C++Builder 5+, or MS Visual Studio 2002+
• Either MFC or BFC; note that these do not come with the free compiler, you'll have to already have them from the full version of either Borland C++ (or Builder) or Microsoft Visual C++.
• libmng, available here.
• A good IDE; I mostly use Ultra-Edit32, or Visual Studio.

Licensing

The source code release is subject to the Andromedia Public License, so make sure you read that before you do anything else. And while it's not explicitly stated in the license, please do not misrepresent your own compiled versions, either as an official Pueblo/UE release or as your own original work. It's not; please don't pretend otherwise.

How to obtain the source code

The latest source code can be obtained from the SourceForge project CVS repository. Once you're familiar with how to use your CVS client, just create an appropriate working directory and use the commands listed under "Anonymous CVS access" in the SourceForge documentation. The modulename is pueblo.

As an alternative to using CVS, you can also obtain an archive of the Pueblo/UE 2.61 complete source tree (including libmng). These files have been packaged for convenience, and I haven't actually tested whether they will build out of the box (though they should, since they're straight from CVS).

Installing libmng

THIS STEP IS NOT NECESSARY IF YOU DOWNLOAD THE ZIPPED SOURCE ARCHIVE

Starting with version 2.60 of Pueblo/UE, the libmng library is used for PNG, MNG, and JPEG image rendering. Go to the libmng site and download lm1008x.zip (make sure you get the 'x' version, as it contains all the other dependencies required by libmng itself). Extract the folders to your Pueblo source directory (so you end up with four subfolders in your source folder).

Here's the really important bit though: in order to get things to compile and run correctly, I had to make a few minor modifications to the source files for libmng and its components. So you should unzip libmng first, and then afterwards copy in the Pueblo source code (overwriting any existing files).

How to compile

There are actually two different compile chains included in the source release; the first is through Borland C++ makefiles, and the second is through Microsoft Visual Studio.NET.

Borland Makefiles

This is what I used for Pueblo/UE 2.60 and earlier. I only stopped in 2.61 and later because it made the advanced crash detection a little easier if I compiled with Visual Studio. After checking out the project from CVS, you'll have to modify the common.mak file in the base directory. This file contains almost all of the machine-specific stuff.

The first thing you should change is the PROJROOT define. This should be the full path to the base directory (where the common.mak file itself is). I know it's not generally well regarded having absolute paths in makefiles, but it seemed the simplest solution to the problem of building multiple makefiles in a recursive manner. Do not leave a trailing backslash.

The CCBIN parameter is the path to the C++ compiler. It defaults to the same directory as the MAKE tool that you are running; you should only need to change this if you're not using the MAKE tool that came with the compiler.

The CCROOT parameter is the path to the other compiler files; it will look for include files in CCROOT\include and library files in CCROOT\lib. The default is the parent directory of the compiler's directory, which should usually be correct.

The MFCINCLUDE and MFCLIB constants tell the makefiles where to find the include and library files for MFC. The defaults are to have the MFC include files in CCROOT\include\mfc and the library files in CCROOT\lib along with everything else. You may need to change this to wherever you installed the MFC files. In addition, if you're not using Borland's version of MFC (called BFC), then you'll have to change the value of the BFC constant at the bottom of the file to match your actual library names.

By default the makefiles are set up to do a release build; if you want to do a debug build instead, just modify the DEBUG constant at the top of common.mak so it reads DEBUG=2. More information can be found in the comments next to it. Note that I haven't actually done a debug build for a long time, since TD32 isn't really very useful, so I'm not completely sure if it still works :)

That should be all you need for the setup. Pueblo/UE has a recursive makefile structure, which means that if you want to build a single component of it, just change into that directory and run your make tool. If you want to build the entire application, do the make from the base directory (where common.mak is). Be aware that there are some dependencies between the various components; the base makefile will build them in the recommended order.

Microsoft Visual C++.NET

This one is basically a no-brainer; everything should in theory already be set up correctly (assuming you've pre-installed libmng as discussed above), just open up the solution in Visual Studio and you should be able to compile and run it immediately. I've been using Visual Studio as my primary debugging tool, incidentally, since it has a fairly decent debugger (considerably better than td32). From 2.61, it has also become my release platform.

So I can compile now. Can I implement awesome new feature XX?

Please send me an email before you start working on some new feature; it's possible that someone else has already thought of it and is already working on it. No sense duplicating work. There also might be some features that I don't want to put into Pueblo/UE (because I think they go against what it's designed for, for example), though hopefully not too many of those. And if you disagree with my decision, just collect enough friends who use Pueblo/UE frequently together and get them to yell at me, and I might come around :-)

I've finished the new feature, tested it, and it works brilliantly. Now what?

Send me a context diff of the changes that you've made; I think you can produce one using WinCVS. Failing that you can use a directory-compare tool to compare your source against clean source straight from the CVS. That way you should be able to find the exact files that you've changed. Again, I'd prefer a context diff if you can produce one, but if not, just package up a zip containing all the modified files (don't include the files that you haven't changed!) and send it to me, along with a detailed description of how your feature works. If it works well I'll integrate it into the next version of Pueblo/UE; if not I might just put the patch up on the site somewhere so that interested parties can tinker with it. Whatever seems more useful at the time ;)

Fin

Well, that's it from me for the moment. If there's anything else you can think of that you need to know, just drop me a line and I'll try to answer.