Rockbox.org home
Downloads
release
dev builds
extras
themes
Documentation
manual
wiki
device status
Support
forums
mailing lists
IRC
Development
bugs
patches
dev guide
Search



Donate

Rockbox mail archive

Subject: key schemes require build process enhancement
From: phil_at_x-phobie.de
Date: 2002-10-04

Momentarily I'm trying to get the tree browser using user assigned
keys.
After that we'll have to discuss the build process. Momentarily I see
two tasks rising:

1.) building the command list
Developers must publish the commands that can be bound to keys
somewhere. I believe that preprocessor macros can't do that job
because it requires collecting data and building a list of all
available commands. Thus I am thinking about a file similar to the
*.lang files here. From this file a *.c and a *.h file could be
generated that contain the command list. We also might want to
generate a documentation file (maybe html, pdf, ...) so that the user
can find the description of the commands somewhere. This process could
include generating a minimal perfect hash for the command list with
gperf.(http://www.gnu.org/software/gperf/gperf.html) In that case
portability of the build process might become an issue?

2.) building the key scheme factory preset
When we have user bindable keys I think it's a good idea to maintain
the factory presets in the file format that we use for loading key
schemes anyway. This way non-programmers could get involved improving
the ui. If we hard-coded the factory presets that would not be
possible and we would have quasi two file formats for the same
purpose. And of course we always would have an example key scheme file
that can be used as base for custom extension and for investigating
how the whole thing works.
For obvious reasons we want rockbox to work even if the user doesn't
explicitly install a key scheme file on the jukebox. Thus we need a
tool that converts key scheme files to c files so that the factory
presets can be compiled in. And of course that tool would have to be
used in the build process, too.
What I consider a bit problematic about this idea is that we should
take care that we don't implement parsing key scheme files twice -
once for rockbox, once for the tool. Keeping that consistent would
open a can of worms we don't need. Thus the source of parsing key
scheme files must be used on different platforms. Would that be the
first source files that are shared between tools- and rockbox-code?
Which directory should contain the source files?

So far my proposals.

Phil

Page was last modified "Jan 10 2012" The Rockbox Crew
aaa