**** BEGIN LOGGING AT Fri Nov 09 02:59:58 2018 Nov 09 10:00:55 morning Nov 09 16:16:26 hello! how does @BASE_SBINDIR@ in systemd .service files work? some packages use sed to replace it with ${base_sbindir}, some don't, and the latter presumably also work... Nov 09 16:16:53 that question is pretty vague. it's not magic, it's case by case Nov 09 16:17:52 hm, i think i actually misread something and all recipes do replace the @@ stuff manually using sed Nov 09 16:18:33 my real questions was: what replaces the @...@ with the value if the recipe doesn't use sed to do it? Nov 09 16:20:45 nothing Nov 09 16:21:02 well, if its an upstream thing, they might be using autoconf to do the change Nov 09 16:21:27 but it depends on the recipe and upstream Nov 09 16:21:51 thanks. i was mainly wondering whether something in systemd bbclass does it. Nov 09 16:24:36 nope, there's no magic for this, it's manual and case by case, either upstream or the recipe. there's no common convention Nov 09 16:25:08 that reminds me, we should really have a common templating mechanism we can use either implicitly against files in SRC_URI or explicitly in a task Nov 09 16:25:16 we seem to do this a fair bit Nov 09 16:26:17 yeah would be useful Nov 09 16:27:01 could get silly and just throw the contents of a file if its called .bbin into a python str.format() and pass the datastore Nov 09 16:28:05 being able to do 'bindir: {bindir}' would be neat Nov 09 16:28:57 the issue with str.format is ${} gets replaced, conflicting syntax. same issue with bitbake expansion syntax if we're templating in a shell script Nov 09 16:29:05 maybe a {{foo}} style Nov 09 16:29:46 iirc that's the mustache-style templating syntax Nov 09 16:30:12 its a shame you can't override the {} characters in format() Nov 09 16:30:22 that would be really useful Nov 09 16:30:28 it really is. it's annoying that most half way decent templating libraries are external Nov 09 16:30:39 and it would be sad to reimplement format() just to change the tokens Nov 09 16:30:43 i can see not wanting one with logic built in, but a more extensible logicless one is reasonable Nov 09 16:31:37 "The str.format() method and the Formatter class share the same syntax for format strings (although in the case of Formatter, subclasses can define their own format string syntax)." Nov 09 16:31:43 ah, maybe Formatter would do the job Nov 09 16:32:06 "The built-in string class provides the ability to do complex variable substitutions and value formatting via the format() method described in PEP 3101. The Formatter class in the string module allows you to create and customize your own string formatting behaviors using the same implementation as the built-in format() method." Nov 09 16:32:25 was just looking at the sources for that Nov 09 16:36:36 while (self->str.start < self->str.end) { Nov 09 16:36:37 switch (c = PyUnicode_READ_CHAR(self->str.str, self->str.start++)) { Nov 09 16:36:38 case '{': Nov 09 16:36:38 case '}': Nov 09 16:36:40 markup_follows = 1; Nov 09 16:36:51 shame you can't just change a variable at the right place Nov 09 16:37:01 hardcoded. so you'd have to replace the formatter parser Nov 09 16:37:03 lovely Nov 09 17:38:34 i gotta say, the cmake bbclass is pretty neat. easy to use and it even shows percentage complete during the build. unfortunately there seems to be no auto-generated cmake .toolchain file for building stuff externally with the sdk. i do that manually when needed, using the sdk's sysroot and a linaro compiler package. Nov 09 17:38:40 the compiler of the sdk is pretty weird. Nov 09 17:45:30 maelcum: I thought it did generate a .toolchain file.... if not, it's possible that it could. Nov 09 17:46:17 * maelcum checks Nov 09 17:47:57 apparently yes, and it looks weird too.. set( OE_QMAKE_PATH_EXTERNAL_HOST_BINS $ENV{OE_QMAKE_PATH_HOST_BINS} ) Nov 09 17:47:59 that is all Nov 09 17:49:09 it obviously expects that the sdk has been sourced, and that stuff is gross. setting $CC and stuff overrides things at the lowest level, which makes a few things operating at a higher level ineffective. Nov 09 17:49:46 e.g. you can't build for different architectures anymore, such as when you need to compile a code generator Nov 09 17:50:17 malecum: You can, you just have to be more careful :) Nov 09 17:50:53 i would say: you can make your build system work with a normal environment, or the oe sdk, but not both, not with the same code anyway. Nov 09 17:52:11 maelcum: I don't know about cmake, but I'm pretty sure you can do it with autotools and others, it just takes some gymnastics. Cross compiling is the hardest way to compile, mixing cross and native compiling is even harder than that Nov 09 17:52:42 it's actually pretty easy with cmake the way i described, using the sysroot from sdk and linaro toolchain Nov 09 17:52:51 But, autotools handles it for example by allowing you to set BUILD_CC & friends for the machine you are building on Nov 09 17:53:14 i mean yeah, the oe sdk pretty much assume autotools, it's crawling with autotools hacks Nov 09 17:53:18 *assumes Nov 09 17:54:32 lots of work to the toolchain in the sdk in master fwiw, older releases were a bit bust Nov 09 17:54:44 you *will* need to source the sdk init though Nov 09 17:55:11 also pretty sure cmake makes it relatively hard to do host/native building in the same thing Nov 09 17:55:24 that is unfortunately true Nov 09 17:55:35 rburton_: Ah. I'm too familar with cmake Nov 09 17:56:08 my most common use case is actually with qmake where i want to make it nice for clients using qt creator... Nov 09 17:56:13 * rburton_ hates cmake with more anger than is acceptable Nov 09 17:56:26 good news! qt have dropped qmake Nov 09 17:56:30 \o/ \o/ \o/ Nov 09 17:56:33 qt creator can switch between "kits" for different targets, and sourcing a different oe sdk and restarting is not how it's meant to be used. Nov 09 17:56:58 this actually doesn't change for cmake Nov 09 17:57:35 so i scrape the qmake options out of the oe build dir and build it again using linaro... i have a bit of routine in that by now. Nov 09 17:57:44 s/qmake/qt configure/ Nov 09 17:59:33 maelcum: Yes, sometimes the OE SDK requires you to do some scraping to make it fit in another tool.... we do something similar in waf Nov 09 18:00:40 JPEW: It's not pretty, but we can mostly hide the ugly magic under the rug so that it "just works" for our developers. Nov 09 18:00:45 what i'd like to have is the oe sdk not relying on overrides at the lowest level like setting $CC. using autotools variables for autotools is just fine. Nov 09 18:01:10 Hah I sent a message to myself... Nov 09 18:01:51 adding things to make it work with another build system is par for the course, but i have to remove and replace things (the toolchain). Nov 09 18:02:13 not really remove, it stays where it's installed, but replace by using something else Nov 09 18:02:46 I don't think I'd consider $CC to be an "autotools" variable, it's just sort of how you do cross compiling? Nov 09 18:03:16 it isn't, i was unclear **** ENDING LOGGING AT Sat Nov 10 02:59:59 2018