WIP: Add TDEMultimedia ebuilds. #157

Noatun isn't building, because it seems to need MPEGLIB (while building!), which needs aRts (while building!) and aRts needs some aRts plugins (while building!) and further and some things are unclear.

JuK, seems to need aKode to build, but at the same time, it can output to aRts and use aRts for decoding, which would allow to make aKode optional, for example. But that isn't the case. In fact, it seems that was possible in KDE3.

KSCD fails to build, even if kscddb is installed already. All aRts related stuff seems to depend on each other (while building!), which makes building them seperate difficult. Some things are missing. So it is still WIP.

It seems here is work needed at TDE level related to the CMake files to make it possible to build components seperately and link against the installed versions. But it can't be wrong already to work on the ebuilds.

Reference: https://mirror.git.trinitydesktop.org/gitea/TDE/tdemultimedia/src/branch/master/CMakeLists.txt#L112

Components which can't be seperately build:

MPEGLIB (Seems to need aRts)
Noatun (Seems to need MPEGLIB, but even if that is installed, it can't find it)
KSCD (Seems to need libkcddb)
KREC (Seems to need KSCD)
KaudioCreator (Seems to need KSCD)
TDEIOSlaves (Seems to need KSCD)

Also it seems JuK had some -WITH_ARTS back in the days, which isn't existing anymore in the CMake conversion.

Signed-off-by: Chris xchrisx@uber.space

I did rebase and resolve conflicts of this old PR and seem to be the only difference that is here is a separate ebuild for mpeglib. If I understand it correctly, mpeglib is now built within ebuild tdemultimedia-arts, so separate ebuild for mpeglib is not necessary?

I reloaded it into this thread, I don't know how it happened))
Since these changes are out of date, I changed the title. You can accept a new commit.

Hmm, I found the previous changes for this branch. Now I will return everything for history and re-upload a new branch, and create a new PR.

The previous override occurred due to the fact that you chose the same too general name of branch as is used in this PR. I now pushed the change as I recently made rebase and merge with current state – see my previous comment.

Hmm, basically I can make mpeglib separate from tdemultimedia-arts. Mpeglib is currently part of tdemultimedia-arts. If you plan to use mpeglib separately, without using arts, then this can be implemented.

Hmm, basically I can make mpeglib separate from tdemultimedia-arts. Mpeglib is currently part of tdemultimedia-arts. If you plan to use mpeglib separately, without using arts, then this can be implemented.

I watched mpeglib is dependent on aRts, so separate use without aRts is not possible. So it seems to make sense to be part of tdemultimedia-arts.

Because all other parts of this PR were already resolved within other PR, this PR probably may be closed without merging a change on mpeglib. What's your opinion?

I watched mpeglib is dependent on aRts, so separate use without aRts is not possible. So it seems to make sense to be part of tdemultimedia-arts.

Checked it. I agree this PR can be closed. At least right now it is impossible to build mpeglib without arts.

WIP: Add TDEMultimedia ebuilds. #157

WIP: Add `TDEMultimedia` ebuilds. #157