build E2 with eplayer3

[zdzislaw22]

You and me have completely different view on the things. You prefere multiple specialized devices, I prefer one having all possible funcitons in it. We cannot say yours or mine is wrong, they are different.
What does it mean from programist perspective? It means the compliation environment need to be flexible. If you like device with only one function included, you should have option to compile the image this way, but when I prefer to have everything in it, I also would like to have such possibility and not be blocked by programist, who does not agree with my approach. (nothing personal, just an example).

The only ask I do have is - Whatever will happen with repository, please do not block anything rather create multiple build options to fit as many needs as possible.

Makes sense?

[Audioniek]

Yes it does. Regarding my git, it will remain a close copy of the git maintained by Max. The things that are different are different because I like my approach better, or things simply do not work in other gits or are obsolete. Examples of these phenomena are:
- My git refuses to build anything if you forget to put in the .elf files (a sensible thing asked for by a user);
- An example of the second the fixed Harddisk.py in OpenPli. No git has it (it is part of the diff-files maintained by me) but the option Menu -> Setup -> Harddisk -> Initialize works as intended when built from my git. If it would not I would patch the menu option right out.
- An example if the third is the flash environment. My git supports flashing any image that fits in all Fortis models.

You can of course use any git you lkie for the a purpose you see fit. The only task I see here for me as maintainer is provide you with a build environment that gives you a much freedom in build options as possible. For this reason the possibility to build with gstreamer only will remain there, because it yields a valid and working image. The option to be able to build with eplayer3 only will either be fixed or disappear altogether because it no longer feasble to build this way. It up to the user of the git on how he/she wants built her image and I, as maintainer will not imposes choices upon the builder. In fact, I will spend time and effort to add an option: build E2 with ffmpeg only, as schpuntik and taapat are apparently doing in their gits. The whole thing is called open source and anybody can do with the code on offer as they see fit, provided they leave the credits in.

With these last sentences we are back on topic. I thank everybody for their feedback, and learned something.

And to put things in perspective somewhat further: next year I will be celebrating my 60th birthday.

Regards,

Audioniek.

[Audioniek]

Hello everybody,

Some posts back I said I would report back when there is something to report, and there is. I finally have been able to reproduce the error reported by kader_73 in the first post:

In file included from service/servicemp3.cpp:14:0:
../lib/service/servicemp3record.h:7:21: fatal error: gst/gst.h: No such file or directory
 #include <gst/gst.h>

When you open the file servicemp3record.h you will find the lettercombination gst a number of times in the code. The first observation is that E2 apparently needs gstreamer by definition, unless this file and its companion servicemp3record.c and possibly others are modified heavily. The short version of the answer to the question posed by kader_73 is: no, the current version of OpenPli E2 cannot be built without gstreamer.

This was already suspected by several others, and they were right. It may be possible to build with eplayer3 only, but this will need extensive patching within OpenPLi to achieve a negative result: you remove features that currently work as they should and which are taken for granted in MIPS-boxes.

My response (git-wise) will be as announced: the option to build with eplayer3 as the only framework will be removed with one of the next pushes. With these pushes you may expect a new more recent diff for OpenPli and a reworked fp_control, that produces better error messages in stead of segmentation faults when it is fed an incorrect command line, combined with usage messages that work as originally intended.

Regards,

Audioniek.