build: implement flexible site-selection system

[blocktrron]

This is currently lacking documentation.
Opening as a draft to obtain feedback whether or not this is moving in the right direction.

---

Implement a flexible system for handling site-defined features as well as packages.

This system is inspired by the existing feature-system and allows for a more flexible approach for selecting specific packages for devices.

Features are now defined in a features file in the site-root. The same goes for packages.

These files are sequentially evaluated and the device-package list is evaluated for each device independently.

[neocturne]

I like the idea of using a Lua DSL here a lot, but I think it would be nicer if features and packages could be configured in the same file, as they are often related. That would also allow to set related conditional features and packages under a single when.

[blocktrron]

Great idea! I'll see how this can be done.

[blocktrron]

@neocturne I've adressed your request, does this look better?

[blocktrron]

Added a first draft of documentation. Example and CI sites still need to be reworked.

[blocktrron]

@neocturne Please see the updated PR, is this more to your liking?

Also yes, negation is still supported, as this is done in handle_pkgs which is not modified.

[neocturne]

Looking quite nice now!

Two remarks (obviously bikeshedding - I'm fine with either solution, just stating my preference):

• Is there a reason you kept the () in addition to the {} for the Packages and Features arguments in the example?
• The capitalization of Packages and Features looks a bit weird IMO

[blocktrron]

@neocturne

No special reason for keeping the (). I can remove them at wish

For the capitalization - My intention was to keep modifying functions with a leading Uppercase while function for the logic evaluation have lowercase first letters.

[neocturne]

@neocturne

No special reason for keeping the (). I can remove them at wish

For the capitalization - My intention was to keep modifying functions with a leading Uppercase while function for the logic evaluation have lowercase first letters.

Using lowercase for everything would be consistent with our target definitions, so if we decide to go with the uppercase names, I would propose to change those as well. Using a consistent function name case still feels more common as a coding style, but I accept that it may make sense to apply different rules to such DSLs.

[blocktrron]

@neocturne I'll opt with all lowercase and maybe revising the docs. Anything from the implementation side i should revise?

[neocturne]

One more idea: How about allowing to specify negated features and packages as -'name' instead of '-name'? I kinda like the separation of the operator from the name.

A very simple implementation might look like this (using the - in the strings would be an implementation detail that we could change in the future):

getmetatable('').__unm = function(s)
	return '-' .. s
end

[blocktrron]

Updated the PR. I have not build-tested the current state yet.

[maurerle]

It would be quite handy to be able to call:
is_cellular_device and is_outdoor_device from platform.lua in the image-customization.lua

gluon/package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

Line 25 in 9a8ee57

function M.is_outdoor_device()

[blocktrron]

@maurerle I would like to hold this back for further improvement. I see this as possible, but we would ahve to build this meta-information from the same source. Possibly the same way as to handling flash-sizes as well as RAM.

[maurerle]

Sure, I am fine with that.
For now I helped myself here - but I don't like the idea of maintaining that list myself:
https://github.com/ffac/site/blob/eb6f98e8ec05957163c3d24115d337cb21ecb97e/image-customization.lua#L25-L36

I just build and tested Firmware from this PR - looks good. I am happy with merging it the way it is.

adressed