Rockbox

I tried this on a 4x Opteron ubuntu linux system using make -j and it seemed to make things a little bit slower, both doing a make clean, and configuring a fresh build. I used arm-elf-gcc (Sansa e200). Any idea why that might be?

Indeed, for a fresh build, things might be slightly slower because of the generation of all dependency files (instead of one for apps, one for firmware, ...).
But, for further builds, when none or few files are modified, the compilation should be faster.

Try it in this way and post your feeling.

Speed difference on my machine (dual core older intel) the speed difference is in the error margin ~0.2 seconds running make -j3 after make clean.
However there's a dependency bug somewhere, if i for example change a file in apps/codecs/Tremor the file is not recompiled and the codec is not rebuilt when running make.

I think there is an open bug which required make to be run twice if a codec is changed so you might have just found that.

To Nils : you are right, I have the same problem

Test again after having applyed this second patch.

Having a build system use a dependency file for each input file isn't a good idea IMO -- this can lead to nasty effects depending on your build environment; at least I'm experiencing such issues every now and then at work (make running on windows, so this most likely might also cause possible issues on cygwin).

jdgordon, yes I know but this was different, the open bug somehow makes the buildsystem fail to relink a codec after compiling in some cases but this caused it to not even be recompiled, so running make twice made no difference.

Christophe, with your second patch I get lots of errors when building a h300 build starting with:

"/home/nils/rockbox/apps/codecs/libspeex/modes.h:39:25: speex/speex.h: No such file or directory"

this problem was not present with just the first patch.

Hi, it's true that those Makefiles are quickly becoming a nightmare to maintain : when you fix a problem on one side, you break something else on another side !
I'm currently evaluating the cmake tool (http://en.wikipedia.org/wiki/CMake) which is a kind of meta make with an higher level of abstraction than Make.
Build directives are very easy to write and, generally, are only half the size of former rockbox Makefiles.
Moreover, rule dependencies between sources and headers are automatically generated.

For the moment, I have successfully converted tools, firmware and I'm converting apps.

I foresee to finish within 3-4 days.
I'll keep you informed.

Christophe, that sounds like a good plan :)
While I am not familiar with cmake, if it makes things easier I am all for it, however i would
recommend you sending a mail to the developers mailing list (or at least discussing this on irc) to
get other devs in on the plan, and get feedback on the idea to not waste effort if a different approach
is strongly favored.

Here a patch which contains the current status of what I've done.
You need to install cmake 2.6 (exists for Linux, Cygwin, MacOSX).

To launch the compilation, cd to directory build-sim-cmake (configured for an iRiver H300 but it doesn't matter for a simulator compilation) and type:
cmake ..

(this will generate various Makefiles)

then type:
make

to launch the compilation (will fail in apps directory where I have stopped translating Makefiles)

If you want to have a look at the work in progress, open various CMakeLists.txt and tools/*.cmake files.

I'm waiting for several feedback to know whether it's worth the effort to continue the switch to cmake.

Bye.

Ooops, it seems the patch contains file build-sim-cmake/cmake_install.cmake
You can safely delete it if it lead to problems.

I've just checked this out against the tree for 18860.

Firstly, the initial call to cmake returned this :

cmake ..
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
Checking for SDL presence ...
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
Ok
CMake Error: Error in cmake code at
/home/bryan/source/rockbox/tools/ucl/CMakeLists.txt:6:
Parse error. Expected a command name, got unquoted argument with text "\ No".
You have called ADD_LIBRARY for library bitmapsmono without any source files. This typically indicates a problem with your CMakeLists.txt file
You have called ADD_LIBRARY for library bitmapsremotemono without any source files. This typically indicates a problem with your CMakeLists.txt file
-- Configuring done



I removed the extraneous stuff from the end of line 6 in the "/home/bryan/source/rockbox/tools/ucl/CMakeLists.txt" file, deleted the cmake_install.cmake file, and re-ran cmake, and got this :

cmake ..
You have called ADD_LIBRARY for library bitmapsmono without any source files. This typically indicates a problem with your CMakeLists.txt file
You have called ADD_LIBRARY for library bitmapsremotemono without any source files. This typically indicates a problem with your CMakeLists.txt file
-- Configuring done
CMake Error: Cannot determine link language for target "bitmapsmono".
CMake Error: Cannot determine link language for target "bitmapsremotemono".
-- Generating done
-- Build files have been written to: /home/bryan/source/rockbox/build-sim-cmake

Not being at all familiar with cmake, I decided to ignore these errors, and proceed anyway. Unsurprisingly perhaps, the build failed.

Hi there, I've not been here for a long time since I worked on 50+ files !
Now, it is quite ready and you can build every target (but only simulator).

Quick HOW TO:
The patch is to be applied against a clean source dir (not on top of diff_cmake1.txt)

As with former build method, create a directory in which to do the build:
mkdir build-sim

Go to this directory and launch configure:
cd build-sim
../tools/configure

NOW SELECT ONLY A SIMULATOR BUILD !!!!
(for the moment, this is the only build type supported !!!)

(cmake is automatically invoked to create the makefiles)

Launch the build:
make

You can also install it after the build succeed:
make install

------------------------------------------------

Remarks:
-------
1)I tried to tell cmake how to handle particular dependencies:
- If a SOURCES files is modified, all corresponding sources are recompiled (this was not detected by former Makefiles !)
- Same behaviour for SUBDIRS file.

2)Generated Makefile supports following general targets:
all (the default one if not specified : build everything)
bin : builds only the rockboxui executable
langs : builds only the *.lng files (not necessary to invoke it directly since it is built as part as rockboxui)
rocks : builds only *.rock plugins
codecs : builds only *.codec
install : install everything in archos/.rockbox

3)But you can also ask to build a particular codec, audiolib or plugin, for example:
make doom.rock
make reversi.rock
make wma.codec
make Tremor (will build libTremor.a)
make a52 (will build liba52.a)
make a52.codec (will build a52.codec)

4)Possibilities to speed-up the build:
By default, the build of a particular target leads to a checks on its dependencies.
For example, if you type:
make wma.codec

Make will checks whether following targets are up to date before really building wma.codec. So you will have :
[ 7%] Built target Tremor
[ 7%] Built target codec
[ 7%] Built target alac
[ 7%] Built target asap
[ 14%] Built target a52
[ 21%] Built target demac
[ 21%] Built target m4a
[ 42%] Built target faad
[ 50%] Built target ffmpegFLAC
[ 71%] Built target speex
[ 78%] Built target musepack
[ 85%] Built target mad
[ 92%] Built target wavpack
[ 92%] Built target wma
[100%] Built target spc

This is normal as all *.codec files depend on all audiolibs (libTremor.a, libm4a.a, ...)

But you can ask to avoid this dependency check if, for example, you only modified wma.c by appending a /fast to the target name:
make wma.codec/fast

This is true for all targets, including the default ones given in point 2)

5)As in former Makefiles, ccache is automatically used if found.
But I didn't success in giving it as parameters to cmake.
So, the only way I found is to create a symlink of ccache into the builddirectory and name it gcc.
Then invoke cmake as:
CC="builddir/gcc" cmake

And it works as expected.



Waiting for your feedback ...

Applied this new patch against 18919, and attempted to build an ipodvideo simulator :

[ 24%] Building C object apps/CMakeFiles/rockboxui.dir/__/lang.c.o
Linking C executable rockboxui
CMakeFiles/rockboxui.dir/gui/icon.c.o:(.data+0x0): undefined reference to `default_icons'
CMakeFiles/rockboxui.dir/misc.c.o: In function `show_logo':
/home/bryan/source/rockbox-18919/apps/misc.c:978: undefined reference to `rockboxlogo'
CMakeFiles/rockboxui.dir/screens.c.o: In function `usb_screen':
/home/bryan/source/rockbox-18919/apps/screens.c:124: undefined reference to `usblogo'
collect2: ld returned 1 exit status
make[2]: *** [apps/rockboxui] Error 1
make[1]: *** [apps/CMakeFiles/rockboxui.dir/all] Error 2
make: *** [all] Error 2

Grrrr, i'm really out of luck with that stuff.
In configure, you chose target 22, isn't it ?

Bizarre since I tried also with an ipod video simulator and the build went ok (cygwin, gcc 3.4.4, ld 2.18.50).
What is the output given by configure (especially gcc/ld version) ?

Could you launch the compilation with VERBOSE=1 flag ?
(forgot to mention this possibility in my previous message)

make VERBOSE=1

Upon back to home, I'll try on my Imac (gcc 4.0.1).

Many thanks for your feedback.

Nota : I just noticed a problem for the install target but it has no relation with your build failure.

Just a quick note to say that I tested the new build system introduced with this patch.
On 50 different targets, 35 were built succesfully and 15 failed because of syntax error in the uisimulator directory (unsupported target as a simulator).

All built with Gcc 4.0.1 on MacOSX.

I quickly skimmed this patch. Some thoughts:
- you haven't removed the old Rockbox Makefiles with that patch. From my understanding those won't be needed anymore -- were they left intentionally?
- is there a way to turn of the color output when building? I guess the buildsystem won't like that too much
- it outputs lines like
[ 67%] Building C object apps/plugins/clock/CMakeFiles/clock.rock.dir/clock_draw_analog.c.o
I find this a bit annoying as (a) there is too much blabbering ("building c object" -- the old "CC" would be nicer IMO) and (b) it refers to some path that isn't reflecting the source path. Having the real source path (and possibly also the source file name instead of the generated object) would be much nicer. Is there a way to tweak cmake doing this? Is there a reason cmake uses filename.c.o for the objects? Looks a bit weird to me, even if that naming is perfectly ok ...

Apart from that I kinda like the idea. I'm curious how this would work for a real target build though as that's still a bit different. Oh, and for the record: tried building ipod video sim, worked fine.