Creating a Library Distribution

The current distribution of Woopsi is all wrong. Wrong, I tells you. As Woopsi is a library, it should be distributed as a library. That means it should come as a set of pre-compiled binaries and header files that can be linked in with other binaries later. This is how libnds, libfat and PALib are distributed.

I’ve had a go at setting this up. It involves completely rejigging the file layout within the Woopsi archive, dumping all of the VC++ stuff in favour of batch files, and adding an extra “make archive” step to both the batch file and the makefile.

The problem is, it doesn’t work. I don’t know why, exactly - I think that I’m missing a few libnds includes somewhere, and there’s something weird going on with the all_gfx stuff. The other problem is that there doesn’t seem to be any way to find out what the problem is as it is just too specific to Woopsi’s code environment.


I think I may need to change the way fonts are loaded from being included via all_gfx to being loaded dynamically using the PALib BMP loader (if there is a BMP loader; a GIF loader would do otherwise). That’ll solve one of the problems, at least. The libnds include is just going to be a matter of trial and error until it works.


Jeff on 2007-10-18 at 23:31 said:

Its worth pointing out, I think, that the distribution of PALib as a compiled binary precludes the inclusion of libreset - if you want to add your own arm7 code, you really need to recompile from source.

I’m particularly biased here because I’m on MacOSX which means that before I can do anything serious, I need to re-implement PAGfx so that I can process my images and fonts into the format that PALib needs - and finding the source to PAGfx was harder than it should be. And batch files and C++ projects are useless, compared to devkitpro makefiles. Its far better if the work is put in to make the library build trivial for the end user.

I’d be more inclined to take an approach similiar to STL - push as much of Woopsi’s functionality into .H files (with inline functions) rather than distributing a .lib (though STL does mandate a .lib as well, I think, for its more exotic bits).

A Woopsi application is really just an instance of a standard class with methods that could quite comfortably be defined in the .h file, overloaded if people care. By doing this, and making them inline, they nop out to nothing if they aren’t called by anyone.

Just my 2c worth.

ant on 2007-10-19 at 05:32 said:

inline functions might be troublesome - Woopsi is a collection of classes. Can you make an inline class or member function? Can’t see how that would work from the compiler’s perspective.

Pushing everything into the h files would be trivial - just reintegrate the member functions from the cpp files back into the class definitions. Sounds like a good idea.

How have you found developing for the DS in OSX? I went for VC++ in Parallels because I use Visual Studio in my day job, but would happily switch for some extra speed.

Jeff on 2007-10-19 at 09:00 said:

Classes only get instantiated if and when you instantiate them. Until then, the compiler knows about them but does not generate any code.

Yes, you can have inline member functions for sure.

If you use inline members, the compile does not generate any code unless they are invoked. If your methods are not inline the compiler has to generate code to populate the C++ vtables under the covers - ie, even though you don’t call them, someone might.

The nice part about it is that you can have a bunch of capability in the inline classes, and the user does:

class MyApplication : WoopsiApplication { void handle_keys(int k) { _handle_keys(k); } }

The library puts the useful functionality into an inline method _handle_keys() and has an overloadable method called handle_keys() which is what it, itself, calls. If the user does not overload the function as above, then nothing happens, but more importantly, no wasted code is included in the end binary.

Whilst it seems like a waste for handling keys, consider more esoteric stuff like “handle_lid_close()“, etc.

As to OSX, it is taking a bit of setting up and the absence of tools like PAGfx is a real pain. But I’ll get there eventually, and its a lot nicer having a Unix to work with than Windows (which is what my day job is)

Jeff on 2007-10-19 at 09:28 said:

Think of all those functions that are in PALib, most of which your normal application would not use, so they are defined as #define’s rather than real code. My guess is that they do it that way so that they don’t contribute to code size unless they actually get used, but you’ve previously observed how susceptible they are to side-effects in arguments (needing to put () around the arguments to DMA_Copy() for example).

If they were made static inline member functions of a class called PALibApplication, then they’d be type-checked for free, and still not contribute to code size, and could have additional side-effects if you wanted ( like recording state information, etc)

Jeff on 2007-10-20 at 00:43 said:

In fact, I went back and looked and lots of PALib is implemented as inline functions - but as stand-alone functions rather than class methods. So they recognise the value of doing things that way as well.