example: for(int i=0; i<n; i++) ;
This should have no side effects
It was already used for android builds
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28021 a1c6a512-1295-4272-9138-f99709370657
Since memory on 32mb ipod videos is mapped twice, a 64mb build still has codecs and plugins mapped in a usable area. This means that all that needs to be done to support 32mb and 64mb boards with the same build is to adjust audiobufend to avoid using more than the actually present RAM.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27960 a1c6a512-1295-4272-9138-f99709370657
General state is: Rockbox is usable (plays music, saves configuration, touchscreen works too).
Problems:
- Playing music in the background (i.e. when switching to another app) doesn't work reliably, but I'm working on that now.
- no cabbiev2 (only some preliminary files for it), no other default theme.
- screen flickers sometimes if the updates are too frequent
- no multi screen apk/package
- strange behavior when a phone call comes in
The java files (and the eclipse project) resides in android/, which is also supposed to be the build folder.
I've put a small README in there for instructions. There are some steps needed after the make part, which are described there,
and which eclipse mostly handles. But there ought to be some script/makefile rules which do that instead in the future.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27668 a1c6a512-1295-4272-9138-f99709370657
For RaaA it evaluates user paths at runtime. For everything but codecs/plugins it will give the path under $HOME/.config/rockbox.org if write access is needed or if the file/folder in question exists there (otherwise it gives /usr/local/share/rockbox).
This allows for installing themes under $HOME as well as having config.cfg and other important files there while installing the application (and default themes) under /usr/local.
On the DAPs it's a no-op, returing /.rockbox directly.
Not converted to use get_user_file_path() are plugins themselves, because RaaA doesn't build plugins yet.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27656 a1c6a512-1295-4272-9138-f99709370657
SIMVER was really only used to detect a simulator build. With APP_TYPE you can
now differentiate between simulator, application, checkwps and database builds.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27372 a1c6a512-1295-4272-9138-f99709370657
EABI is now the default for all targets, but --no-eabi is still
available for testing purposes
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27361 a1c6a512-1295-4272-9138-f99709370657
It still works mostly like the simulator. There's also some minor left overs from the sim, but it does not define SIMULATOR.
It installs into the current (build) dir, and you need to run it with '--root .' (because it looks for ./.rockbox and not ./simdisk/rockbox) as options. That's one of the few kludges left that should be resolved soon'ish.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27310 a1c6a512-1295-4272-9138-f99709370657
- windows linker doesn't support -z defs
- rename 'crosscompile' variable to 'win32crosscompile' to show its real meaning
- do not test which host we are running on if we are cross compiling for win32
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27283 a1c6a512-1295-4272-9138-f99709370657
Running the linker with -z defs will error out if a shared library (such as a simulator codec/plugin) uses an undefined symbol
Replace a bunch of sed s,XX,YY, by s<XX<YY< because GCCOPTS will contain the ","
I chosed "<" because it's a weird character to be found in a PATH/option, but any character which wouldn't be present in XX or YY would do
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27256 a1c6a512-1295-4272-9138-f99709370657
