[tadly]

Thanks for taking the time

This is because your PictureItConfig.cmake does not set PICTUREIT_LIB_DIR.

Hm.. As of right now it works though.

I'll set up a LXC container on my NAS later today and set up a proper build-environment for binary addons
https://github.com/notspiff/kodi-cmake/b...ADME.linux
Not all the info I need, but it will get me started at least

- You should put your headers in in the src dir, right besides the cpps

Really? I did a lot of googeling and most people said it's better to have the headers in a separate folder "include".
Having them side-by-side with the cpp's was what I had initially and than forced myself to restructure the whole project :/

- the depends dir is not meant to put headers or libraries directly. Its intended use is to put definitions(usually an URL to a tarball or github repo) of libraries, your addon needs. Our kodi cmake addon buildsystem will then automatically download and build those dependencies. This won't be used on standalone building(=clone addon repo, cmake, make install) though. In that case you have to install all needed dependencies (system wide) manually.

Hm I see.
That's probably java shining through a bit as I like to have everything project related within my project.

So let's say PictureIt depends on stb_image.h and boost-filesystem (might have to used that in the future for dir-listing).
How would you go about managing/adding those dependencies?
For PictureIt itself I could say "boost is a necessary dependency, so install it if want to use PictureIt in your project"
For visualization.pictureit I have to have everything included meaning the depends-folder would have a link to boost-filesystem
and my CMakeLists.txt would link it?

Would it be okay to have stb_image.h somewhere in my project? If so, where would be the best place to put it?
I don't like putting external resources into my src (or include) dir. Personally I like to have things separated and well organized

Edit:
btw, I pushed everything to github now
https://github.com/linuxwhatelse/PictureIt
https://github.com/linuxwhatelse/visuali...t/tree/dev
I know the structure of the visualization.picture dev branch is plain wrong but in my defense...
...It got late and my brain wasn't functioning properly anymore ^^

[wsnipex]

in the end its up to you how you structure your stuff. The differentiation between includes(headers) and libs is only important for installation dirs,
on Install, headers go to $prefix/include and libs to $prefix/lib.

stb_image.h is a boarder case imho, since its a header only "lib". Personally I'd put it in src/contrib, but preferences vary and we don't have any hard standards for that.

Boost is a different kind of pain. On the one hand, kodi already requires it(hopefully not long anymore) so its there already if you build with our intree build system(https://github.com/xbmc/xbmc/tree/master...ake/addons).
Otoh you would have to add it to depends to conform 100% to the "standards" of said build sys. This would be a matter of discussion and I can't offer a definitive answer.
Lets see what ironic_monkey/notspiff thinks about it.
For standalone building you can simply require the user to make boost available on the system.

see e.g. https://github.com/xbmc/audioencoder.lam...ommon/lame on how to define dependencies in your addon.

[ironic_monkey]

boost is a prime example of a lib that should not be provided by the core (cause then it's tied to a kodi version). code quite often rely on particular versions of boost. as painful as it might be, i'd say it needs to go in depends/

[tadly]

in the end its up to you how you structure your stuff. The differentiation between includes(headers) and libs is only important for installation dirs,
on Install, headers go to $prefix/include and libs to $prefix/lib.

stb_image.h is a boarder case imho, since its a header only "lib". Personally I'd put it in src/contrib, but preferences vary and we don't have any hard standards for that.

Boost is a different kind of pain. On the one hand, kodi already requires it(hopefully not long anymore) so its there already if you build with our intree build system(https://github.com/xbmc/xbmc/tree/master...ake/addons).
Otoh you would have to add it to depends to conform 100% to the "standards" of said build sys. This would be a matter of discussion and I can't offer a definitive answer.
Lets see what ironic_monkey/notspiff thinks about it.
For standalone building you can simply require the user to make boost available on the system.

see e.g. https://github.com/xbmc/audioencoder.lam...ommon/lame on how to define dependencies in your addon.

Well.. personal preference will always be a thing but I have no problem to follow some preferences instead of coming up with my own
where everyone would start scratching there heads ^^
And as you most likely can tell, I lack quite some experience right now (trying hard to gain some though) and that's why I keep asking
in case I don't find a answer while googeling (or get super confused because of different opinions)

So, I'll move stb_image to src/contrib than, that's fine with me and separates it from my source nicely

Yeah, boost will be quite something. All I need is cross-platform directory listing which has to be part of the core project (PictureIt) and therefor
I can use any of Kodis implementations.
The add-on part would need directory-listing as well to define the presets (as they are the defined by all available subdirectories).
I'd end up using the implementation made in PictureIt than (I think)

For now my priority is to to get the overall structure and cmake scripts right so I don't end up with the most hacky and awkward thing one has ever seen

[tadly]

boost is a prime example of a lib that should not be provided by the core (cause then it's tied to a kodi version). code quite often rely on particular versions of boost. as painful as it might be, i'd say it needs to go in depends/

Do you mean "depends/" of PictureIt or "depends/" of visualization.pictureit?
Because it would be required by PictureIt which is it's own project (and doesn't need Kodi)

[ironic_monkey]

then you have two dependencies in your visualization.
- PictureIt
- boost (dependency of a dependency). both of these should be separate depends/ entries, pulling PictureIt from a git or a tarball. then you add boost as a dependency in the PictureIt definition (deps.txt)

[tadly]

If I don't find a dirent cross-platform wrapper thing, than I'll look into boost in the future.
But as I really only need directory-listing, I'd like to keep the project as small as possible with as less
dependencies as possible
(hope that's the right decision ^^)

And again, thanks a lot you two (Not long until I add that to my signature here on the forum )

[ironic_monkey]

in my fork i have support for that in the addon callback classes (it uses the kodi vfs so you can list remote dirs and such as well). i'll see if i can find some time to separate out that bit of my stuff and submit to mainline. busy ant these days though so may take some time.

[tadly]

in my fork i have support for that in the addon callback classes (it uses the kodi vfs so you can list remote dirs and such as well). i'll see if i can find some time to separate out that bit of my stuff and submit to mainline. busy ant these days though so may take some time.

That's something I've been thinking about as well..
But this will be a huge problem to integrate as PictureIt (the kodi-unrelated core) takes a folder path and search for images on it's own.
This will be impossible if the path would be one of kodis vfs-based ones.

The reason why I put that into the core is to ease the implementation.

Code:

...
pictureit->load_images("path-to-folder-with-images");
...
//Render-method of a random framework
void Render() {
    pictureit->render();
}

and you'r pretty much done.
Find the images, loading them into a texture, displaying them randomly etc. all will be done by the core (most can be configured)

If I want vfs to work, the project implementing PictureIt would have to do some serious work to keep things efficient.
Namely loading images into objects (using e.g. stb_image.h) and provide those to the core.
Hm.. I could define callbacks that would be call whenever I need a new image.. that might work.

I'd have to put way more thought into that ^^

[ironic_monkey]

yeah, callbacks is the solution. just have the user of the library provide something, then wrap that to the kodi solution outside.

granted, it might just be a bit over-engineered. tbh i don't see why you can't just use dirent? it is available on all platforms you are interested in (opengl, so linux, osx or win32, see https://github.com/xbmc/xbmc/blob/master...2/dirent.h)

[tadly]

I might go for the callback solution than. Will be on a low prio for now though...

Oh wow..
But it's not available on windows like out-of-the-box right? on every unix system (at least that's what I read so far) it is present

So I basically just have to make sure that on unix-systems I use the systems dirent.h and on win32 I used the one I included with my project.

Would I put the header in e.g. src/contrib/win32 than to keep it separated?

[ironic_monkey]

that sounds sane yeah. and then make sure to add that include path on win32 only in CMakeLists.txt. that way you simply include dirent.h in your code, and move on. no platform handling needed in the code (for that part anyways).

[tadly]

Hm, that raises one question...

as wsnipex suggested, it would be better to have my project's header files alongside with my *cpp's
this means I'd tell cmake to

include_directories(${PROJECT_SOURCE_DIR}/src) # I use a variable INCLUDES, this is just for demonstration purposes

within ${PROJECT_SOURCE_DIR}/src lies the contrib folder and win32 is part of contrib.

as far as I can tell, include_directories works recursive, meaning the win32 folder would be included if I want
it or not

So, should I add each header file to my INCLUDES variable manually and only add the win32 dir in case of windows?

[AchimTuran]

You don't need boost for dir listing.

Spiff did a PR for vfs.

https://github.com/xbmc/xbmc/pull/8450

[ironic_monkey]

Nothing is recursive. You would have to include win32/dirent.h if you only add src/contrib to include paths.