 May 5 2008, 04:26 PM
|
Anyone who was on IRC this past weekend knows that I was looking for a solution to building our software on Linux. Makefiles are fine, but can easily get out of hand. I tried SCons, which was too verbose and supposedly doesn't scale down well. I tried CMake, but the lack of proper tutorials, and the lack of custom configurations (even though they say you can add new configurations), was frustrating. I tried boost build, but it was not able to fit in with our directory structure, unless I missed the docs on it, or it's undocumented. Finally last I settled for premake, which does 90% of what I need it to. The remaining 10% is fairly critical to this project, but I was able to work around it, and supposedly the features I need will be added eventually. Unfortunately I was not able to get the PWToolBox Python configuration built last night. Ultimately, nothing out there was able to give me the flexibility and scalability that I needed.
So this weekend was an exercise in failure.
When I got into work this morning I remembered that I had nothing to do. Luckily I had nothing to do all day. I was able to write a program that I like to call Mage, which stands for Makefile Generator.
First off, Mage is not meant to be a cross-platform build tool (there are exceptions, see below). It will not generate project files for Visual Studio or Code::Blocks. It only generates Makefiles. Mage is essentially just a thin layer above make that makes it easy to customize your build process. It does not attempt to figure out settings for you based on configuration types. If you want all your projects to share common compiler flags (for example, debug and release flags), then simply write a Python script that stores these flags and import them in every build script. Alternatively, you could write a wrapper around Mage that handles those settings for you.
So what features does Mage have?- Builds a Makefile (duh). It does not compile your program. After generating the Makefile you simply run Make to do that.
- Build scripts are plain old Python programs. No need to install anything else. No need to run a separate tool over the script. You have the full power of Python to do your bidding. Just type "python <name_of_script>" and a makefile is generated for you.
- Mage is written in Python, with no supporting libraries. Just install it as a python package and you're ready to use it.
- The command line is completely accessable through the build script. Anything you can do with Makefiles you can do with Mage.
- Mage will detect dependencies between files. This eliminates the tediousness of Makefiles and allows for minimal rebuilds.
- Specify program type. You tell Mage what type of program you are building (executable, static library, or shared library) and it will fill in the correct compiler and linker flags. You could also specify the value None and control those flags yourself. As of now, the exe works fine, the shared library builds, but I haven't tested it, and I haven't implemented the static library.
- Uses the Visual Studio style Solution, Project, Configuration setup. This produces a target called <Solution>, a target for each project in the solution called <Solution>_<Project>, and a target for each configuration of each project in the solution called <Solution>_<Project>_<Configuration>. This allows you to make the entire Solution, make on a per-project basis, or make on a per-configuration basis.
- Supports aliasing targets. Don't like the names that are generated for you? Want the target name PWToolBox_PWToolBox_Debug to be renamed to PWToolBox_d? Yup, you can do it. (Well actually right now you can't, but the important thing is that you will be able to do it).
- Customizable directory structure. Supports placement of binary files and object files into specified directories on a per-configuration basis.
- Exclude files from a configuration. This is handy when working with SWIG. When you don't want to build a wrapper just exclude the file from the configuration.
- Add variables to the makefile configuration. If you want the user to specify the boost includes directory, just add a variable and give it a default. The Makefile will use that variable to determine the path. (This feature isn't implemented yet)
- Pre and Post build scripts. Pass a list of command lines that you want to run at certain stages of the build. (This isn't implemented yet)
- Readable Makefiles. Maybe you want Mage to generate a Makefile for you, but afterwards you'd rather handle it yourself. The generated makefiles are very readable, and include comments outlining the solution, project, and configuration sections of the makefile. It's very easy to find out what part of the Makefile is building what configuration just by glancing at the file.
- Portable to Windows. If you have Cygwin installed you can run Mage and generate makefiles. You can then run make as normal. Thanks to Cygwin, you don't even have to be in a Cygwin shell to do it. This is actually how Mage was created. You can use Python to help get around platform-specific issues.
Not bad for 8 hours of work. I'll probably have this up in SVN on Wednesday (that's the soonest I can get access to SVN again), and we'll probably release it with PWToolBox. Don't know the license yet. I was thinking of going GPL with this one though.
|
|
|
|
|
Apr 28 2008, 03:47 PM
|
Over this past weekend I've made a major milestone on PWToolBox. All major development has stopped. There are only a few minor things to finish up. Ethan has been working on writing unit tests for it, and I hope that within a month we can release PWToolBox 1.0.
Even as I type this there are already plenty of ideas floating around (and some even partially implemented) for the next version of PWToolBox. Will the work on PWToolBox ever end? Probably not. The more we implement in PWToolBox (and other supporting libraries), the less we have to do for the client, so in effect, the client is making progress. Additionally, by releasing PWToolBox to the public, we can get other people to put the library through some real-life testing. That should save some time for us as well.
This news comes with more good news. Last Friday we finally reached that milestone at work I was talking about in February. From here through July it will just be some bug fixes.
So that's about it for now. Lots of excited stuff coming up (well, if you're a programmer anyways). Look for the first release of PWToolBox within a month!
|
|
|
|
|
Nov 4 2007, 12:31 PM
|
|
Over the last few weeks I have implemented a component-based object system and dataports. Quite fun stuff, if you're a geek. I was also able to make use of boost's call_traits and type_traits library for the first time. They were very useful for implementing dataports. I think within a few weeks these will be reviewed and merged into the PWToolBox library. Then I'll get back to the tech demo. I promise. Of course now I have to refactor it to use these new systems. Fun stuff ahead.
|
|
|
|
|
Dec 4 2006, 08:54 PM
|
|
Well today I worked a bit with OpenMP. It's not the first parallel stuff I've written, so the concepts are easy. What I like most about it is being able to incrementally parallelize your code. Its also nice that you don't have to deal with the lower level stuff of determining which threads do what. After working with MPI and UPC, I can say that OpenMP is much better. It'll probably end up being what is used for the client for multiprocessing. The good thing about it is the client can be developed sequentially and then we just go in and parallelize the bottlenecks or other code that just makes sense to do so. I don't know what direction the server team will take for parallel code. I suspect it will probably end up being MPI or a hybrid approach, combining OpenMP and MPI, which is a fairly popular approach. They have the additional complexity of not really knowing what server hardware to expect. Glad I don't have to worry about it.
|
|
|
|
|
Nov 24 2006, 08:29 PM
|
So a couple days ago I laid down the first lines of code for the game engine. The engine is still unnamed as of now. As of now the engine initializes Ogre and that is about it. I spent the night at the bar thinking of how to implement the input system, which will be the next thing to be implemented. Yesterday I also exposed a portion of the engine to Python via Boost.Python. I'm still learning how to do the wrappings though.
I'm surprised I got anything done this week actually. Games were on sale at the video store this week for $8 so I picked up 7 of them, and have been playing them regularly at the expense of Morrowind. Next weeks starts the 3-week crunch time up until final exam week, and then I get a month off. Kent (effigydrums on here) and I have some pretty cool plans for video games and drinking over winter break, and of course some PW stuff will get done.
|
|
|
|
|
Sep 26 2006, 12:22 PM
|
Well we finally released the first version of Dwarf. Feels good. Now we can start working on new features and projects. I suppose I can leak the next feature that I'm going to put into Dwarf. It'll be an auto-save. This should be very helpful considering the editor is only in its alpha stage and prone to crashing.
The quest for auto-save gave me another idea. Instead of just writing the auto-save, I'll generalize it into a task manager system and have different kinds of tasks available to run, or you can customize your own task by subclassing the task class. All is fine and dandy in theory. However, I decided to use the boost multi_index class to help me with the system. For those unfamiliar with it, as I know most of you are, it allows you to have multiple views over data, kind of like a relational database. Cool.
So I spent a couple days writing the system up, with good initial results. As I further tested the system it became apparent something was seriously wrong. Tasks were disappearing without having been completed. I traced this down to me not using the multi_index class right. Stupid me didn't read that by default sets are non-mutable, and you have to use special functions to mutate them. Ok, well I figured that out and my tasks were no longer disappearing. Then I came to the realization that if I tried modify states of tasks after I retrieved them (say for instance one task triggers another to start), the underlying set structure wouldn't rearrange itself, and to do so might cost valuable time.
So here I am, at the crossroads of a design decision. I guess over the next week I'll play around with it a bit and try to solve the problem. The good thing is that it is very easy to swap out the underlying structure.
Now its off to do some homework. In the next two weeks I have 3 exams, 2 programs, and a paper due (in "computer science" style, whatever the hell that is supposed to mean).
|
|
|
|
|
Aug 6 2006, 09:29 PM
|
Well this week was relatively slow for me, and I didn't do any development on Dwarf until today. I redid the object editing system so now it's easier to place objects how you want them. Simply click on the object, hit a hotkey or two, and move the mouse. Another much requested feature that I implemented was the ability to delete objects. I guess the next step I want to implement is a little xyz display in the corner that displays the information relative to the current operation on the object, and allowing to you type in values for more accurate control of the objects. Another feature I want to implement, and this is pretty easy, is detecting if dwarf is already running and preventing you from opening another copy of it. I accidently opened dwarf twice today and it cause an error and then my system started slowing down, forcing a restart.
The editor is really coming along nicely, and I'd love to show you all some screenshots, but I'm going to make you wait until the official alpha release of dwarf.
Now its time for Caddyshack and Morrowind.
|
|
|
|
|
Jul 31 2006, 12:36 AM
|
When one hears "bugs" and "pointers" in the same phrase, one tends to associate them, at least if you're a C or C++ programmer. Today was one of those rare cases when the bugs were not tracked down to pointer problems (well, all except one).
I fixed a few annoying bugs in Dwarf today, the most annoying being the program crashing anytime you released the left control key. I traced it down to some code that was apparently outdated and depended on a pointer being initialized, which it wasn't. I put a guard in there to get rid of the problem and then commented the call out because I don't think it actually made anything happen in the editor anymore. Bug 1 down.
Another problem was a bit trickier to catch. Apparently in CEGUI if you drop down a list box and click away from it so it hides the list, it doesn't get a deactivation message. This caused the list box to not get clipped by the parent window when it was rolled up and you ended up with a list box floating around in the middle of nowhere. I realized I was catching the wrong messages and changed the code and it worked. Bug 2 down.
Another bug had to do with the way the editor starts up. It depended on a default map to be present, and also had two different paths for loading a map, one dedicated to the first time a map was loaded, and one for the rest of the time. This caused a problem where the settings wouldn't be in sync with the world. It was a pretty simple fix to get the map to load in by calling the other code path and adding a reset function to the settings that would update the settings to the current environment. Bug 3 down.
So I was done with bug squashing for the day, but it was still early so I decided to finally get rid of all raw pointers and replace them with boost's scoped pointer. Normally this is an easy task. Unfortunately for me Dwarf has a bunch of header files that include eachother and a couple global variables. Pointers were used throughout the classes though so it compiled. But when I changed over to the boost pointers i needed the actual object, not a pointer to it. So After about 30 minutes I hashed out a fix to the headers and started the boring task of coverting, compiling, and testing, which lasted about 2 hours.
After all of that I was ready to wrap it up for the night. I had forgotten about a simple feature I was going to add. I wanted to make the titlebar reflect the name of the map that was currently open. I guess I'll get to that later.
On to the personal stuff. Why am I feeling beaten up? Well, it's not from the development I did today. That was fairly easy stuff. I had a pretty big weekend though.
Friday I played Nazi Deathfest (or Brothers in arms as it's more commonly referred to) with a friend of mine. We beat all the skirmishes on the advanced mode and we're ready to go up to the veteren setting. There was this one mission called "Defending the Line" where you play as the Germans and you have to clear wave after wave of Americans. Towards about the halfway point you get pushed back to a bombed out house. It was at this point that we realized there were 4 squads (each squad with 3 men) coming for us. They converged in the trenches in front of us and did an all-out charge up the center. My friend picked up a BAR from a dead American and I had the FG-42. We fired until our clips ran out, blinded by the muzzle flash. When I ran out I was facing a wall and looked outside the window in time to see the last one fall dead. Thankfully we had both of our sqauds with us or we would've been dead.
Saturday was a great day. Got up early to prepare for Cajunfest, which is just a big pot-luck picnic where you get some of the best cajun food for free. I made black-eyed peas with smoked pork butt, which also made a very good warm chip dip. At the festival they had some excellent food. They had shrimp, crawfish, salmon, marlin, seafood creole, cajun lasagne, chicken, meat pies, spaghetti, and probably some things I can't remember. For dessert we had a variety of things, including rhubarb pie, rum balls, two-ton burbon cake, boiled peanuts, mini pecan pies, and some other dishes I can't remember. I probably can't remember a lot of stuff because there were 3 kegs of beer there, to which I was very fond of.
Saturday night was also fun. I got together with a couple friends, had some good beers and used the shitty ones to boil brats in. The brats we had were supposed to be Wisconsin's best, and they were damn good. I don't remember a lot of the night because we had quite a bit of beer. I think one of my friends and his girlfriend kept sneaking off to make out somewhere.
Sunday morning we got up and went to this place in Oconomowoc where we had Belgium waffles al la mode with whipped cream and syrup. Usually they offer chocolate sauce for it as well, but they didn't today. After that we went home and I started working on Dwarf.
My cold is finally clearing up too (and thankfully the swelling has gone down). Now it's time to relax for the rest of the night.
|
|
|
|
|
Jul 21 2006, 06:47 PM
|
It's great when things just work. Of course that didn't happen to me when I tried adding boost to svn. All the files added fine, but the commit failed towards the end. However, all the files were uploaded. On my local copy it still said the files were added but not commited. An hour later and I finally had everything working again.
On the other hand, I wasn't sure something would work today and it did the first time I tried it. I was working on Dwarf, trying to allow you to change the material applied to the ocean, and I realized I needed a list of materials parsed by Ogre. Luckily for me the MaterialManager had an iterator that allowed me to get that information and it worked like a charm right away.
On a personal note, I'm still have a cold with a sporadic fever. It feels like a walrus is stuck in my sinuses.
|
|
|
|
2 Pages  1 2 >
|
 Info/Links
About the author
Blog categories
Blog stats
Views: 26630
Entries: 14
Blog created: Nov 23 2006, 01:25 AM
|
