More on the asset pipeline

So I'm still trying to figure out what my asset pipeline is going to be like.  What makes it particularly interesting is this:  the GBA doesn't support files (there are hacks out there to simulate it, but I'd prefer not to use them).  Everything gets packed as data into the single game rom, and run.  The DS, on the other hand (at least for homebrew) has a usable filesystem.  Now you can ignore the filesystem and pack things into the rom like I did for the DS release of Anguna, but working with files can sometimes be a lot nicer -- it sure makes the edit/build/test cycle a lot easier, as you don't have to go through a separate compile step.

The tricky part is thinking about how I might implement both of these.  The core of my existing engine assumes everything exists as structs in C, and references to other data is just via pointers.  (Which is easy when the compiler does all the work for you).  But if I use files, I'll basically need to write a file parser, which will then populate those structs, and create all the pointers between the new structs based on text symbols in the files.  Definitely doable, but a bit more work.  Is it worth it to go to files for the DS but not for GBA? 

The other side of the coin is the argument that, realistically, when editing assets, I'll already have to jump through some hoops to save/export it properly using whatever tool I use.  Why not just make sure my tool also recompiles everything during that step, and let the C compiler do all the work of parsing, populating structs, and creating the pointers?