On 2 May 2017 at 19:18, Felix Fietkau <n...@nbd.name> wrote: > On 2017-05-02 17:53, Roman Yeryomin wrote: >> On 2 May 2017 at 10:25, Felix Fietkau <n...@nbd.name> wrote: >>> board_name already exists, and I've already converted e.g. the lantiq >>> target to use it directly from functions.sh. >>> board_model is not used, neither is the model function from any of the >>> messy copy&paste target files. Which means you're arguing for having a >>> separate source file for a function that in its current form only has >>> one single line of code. >>> >>> In my opinion the best course of action is to nuke your patches 1-3 >>> completely, rework patch 4 to adjust the generic code as proposed, and >>> adjust patch 5 to simply use the board_name() from /lib/functions.sh >>> >>> Just ignore the board_model nonsense, it does not need to be part of the >>> shell 'API' at all. >> >> I'm talking about board_name, not model. I've added model to the file >> only because /tmp/sysinfo/model exists. >> You say that including 365 (non-functional) lines is better than 15 >> (functional) when you only need board_name? I cannot understand >> that... > I'd say almost all places that will use board_name() already need > /lib/functions.sh. > /lib/functions/uci-defaults.sh already includes it, so do many other > core include files. > Among the files touched by your rework, I think there is only one file > that does not already include functions.sh. > > In functions.sh we already do have quite a few functions that are used > only in some places and not in others. Putting every small piece into a > separate include file would make things messy very quickly. > > This may seem like a minor detail to you, but I want to make sure that > we don't add more unnecessary clutter here.
I just want to save maintenance time. As you admit it's already a clutter. I'm trying to introduce some order. Actually uci-defaults is another one which doesn't need 90% of functions.sh (it only needs list_contains). I would propose breaking down functions.sh into smaller files by functionality, e.g. config/user/base/etc., together with optimizing it's usage in other scripts. Then /lib/functions.sh could become a meta include which includes everything under /lib/functions/. It would be more logical and structurally more right than including functions.sh from a script from /lib/functions/. Regards, Roman _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev