**** BEGIN LOGGING AT Thu Sep 08 02:59:58 2016 Sep 08 13:34:25 hello Sep 08 13:37:21 ive been trying to get this cmake based code to work with yocto/oe for some time. Sep 08 13:37:42 i really don't know if I'm working on it the right way. Sep 08 13:38:14 my problem is that this cmake project is kind of like a two stage build. Sep 08 13:38:27 you run cmake and it builds makefiles. Sep 08 13:38:47 these makefiles take xml files and builds executables. Sep 08 13:39:01 these executables are run and they generate new .cpp files. Sep 08 13:39:30 later the cmake generated makefiles will build the final exes from the generated .cpp files. Sep 08 13:40:31 so i thought i could work this problem by building the code with two recipes. the first recipe would build the entire project as a HOST/NATIVE build Sep 08 13:41:27 i'm not sure of syntax nomenclature, but I think it would be considered a host or native build. Sep 08 13:42:08 but it so that bitbake can build the code so it can run on the host. It can run those generator programs during make to build the exes Sep 08 13:42:33 iirc cmake has built-in support for "use this compiler to generate code that i can run on the build host" vs "use this compiler to generate code for the target" Sep 08 13:42:36 which is basically what you want Sep 08 13:44:12 cmake has a cross_compiling flag, which is set to false when I build this code standalone outside of bitbake. Sep 08 13:44:28 but when I run in bitbake it gets set true. Sep 08 13:44:44 yes Sep 08 13:44:48 because you're cross compiling Sep 08 13:44:59 anyway, so I was able to get bitbake to build this code as native. Sep 08 13:45:14 yes because then you are not cross compiling Sep 08 13:45:39 hm maybe i'm thinking of meson Sep 08 13:45:44 and cmake just doesn't support this easily Sep 08 13:45:46 i had messed up and made a recipe with -native suffix. Sep 08 13:45:47 (cos cmake sucks) Sep 08 13:46:12 rburton1: trust me. I know cmake sucks. but I'm trying to help people out who like it. Sep 08 13:46:30 https://cmake.org/Wiki/CMake_Cross_Compiling#Using_executables_in_the_build_created_during_the_build Sep 08 13:46:56 that's the hack to build binaries that are needed to run in the build Sep 08 13:47:13 so anyway, I had this native cmake project working. I got to 100% in my do_compile task and was able to install just the exe's i needed to the x86_64 sysroot Sep 08 13:47:15 so yeah you want a native recipe that builds those tools and installs them, then a target build that depends on the native recipe and uses the tools Sep 08 13:47:31 rburton1: you are a smart man. that is exactly the plan. Sep 08 13:47:57 but when I got over to the target recepe work, the cmake build during make was failing again. Sep 08 13:48:19 it was odd, it was failing because it could not find these exes which it needed to use. Sep 08 13:48:35 generally you'll need to fiddle the cmake so that there is a way to say "don't build these tools, use them from " Sep 08 13:48:45 i was confused. they are in the sysroot, why cant it not find them? Sep 08 13:48:54 your cmakelists Sep 08 13:49:34 so I said to myself, let me build the image using the -c populate_sdk switch. I'll install the tools that way and use them to debug the build. Sep 08 13:49:41 eww Sep 08 13:49:44 when i did that, bitbake failed. Sep 08 13:49:50 the native form will just put them in the sysroot as you said Sep 08 13:50:00 if they're there then its up to you and your cmake patching to do the right thing Sep 08 13:50:00 so I tried to build the base image again and it failed. Sep 08 13:50:41 when in doubt, rm tmp and try again Sep 08 13:50:54 so i read some mailing list archives and talked to some folks and saw maybe I'm doing this wrong. Sep 08 13:51:27 instead of having two recipes, pcmx and pcmx-native, I should have one receipe which builds as a nativesdk Sep 08 13:51:52 i did that and it got to the point where it tried to run the exes and it failed. Sep 08 13:51:56 why are you bringing nativesdk into this? Sep 08 13:52:12 rburton1: i'm a dumbass? Idk. Sep 08 13:52:43 step 1 is hack the cmakelists so that you can install the tools and do that in class-native to put them in the sysroot Sep 08 13:53:03 i thought if it was a nativesdk, it would include the tools as part of the build. Sep 08 13:53:12 step 2 is to hack the cmakelists so that it skips building the tools in cross compile mode Sep 08 13:53:32 nativesdk is for packages which are in a SDK. unless you're building a sdk they are not relevant. Sep 08 13:54:25 so, i kind of do need it in the nativesdk Sep 08 13:54:39 i'd worry about target and native before sdk Sep 08 13:54:45 because not everyone here is going to want to use bitbake Sep 08 13:55:19 i need to be able each morning to give them the sdk tar file and say, here install this and now you can build your code for testing on the target machines. Sep 08 13:55:42 in this case i suspect native and nativesdk will be identical as it will just build those tools Sep 08 13:55:48 rburton1: yes, you are smart I need to worry about native and target Sep 08 13:55:52 first Sep 08 13:56:29 so i appreciate your helpfull directions Sep 08 13:56:56 if you have colleagues who love cmake so much point them at that wiki page and explain the problem :) Sep 08 13:56:56 so to get to final objective, how many recipes should I have? three? Sep 08 13:57:00 one recipe file Sep 08 13:57:06 bbclassextend=native Sep 08 13:57:14 and then some native-specific bits in it Sep 08 13:57:45 like https://github.com/rossburton/meta-beignet/blob/ross/recipes-opencl/beignet/beignet_1.1.2.bb Sep 08 13:57:51 so I should get back to where I can build the code 100% for the host and ahve it populate the sysroot for the host tools Sep 08 13:58:22 I can revert back to that. will that break the final image build and sdk build? Sep 08 13:58:52 i endorse git to manage your changes Sep 08 14:15:33 rburton1: ok, besides erasing and starting over. is there a way to get rid of this nativesdk-pcmx dependency? Sep 08 14:16:35 i can't really answer that without having all your stuff Sep 08 14:16:58 yah, i'm going to just rm -rf and start fresh Sep 08 14:17:15 delete tmp and it will all be pulled from sstate anyway Sep 08 14:17:19 ive been doing this so much it takes so long to retry Sep 08 14:18:06 so if I understand correctly, I dont need my image receipe to require this layer right? Sep 08 14:19:16 I guess what I'm saying is , step one, get it working for host build. Sep 08 14:19:26 step 2, get target build to work. Sep 08 14:19:38 step 3, get it in native sdk to work Sep 08 14:20:09 for step 1, it does not need to be in my final image, just build it as a stand alone target. $bitbake pcmx Sep 08 14:21:00 yeah just focus on the recipe Sep 08 14:21:06 roger that Sep 08 14:22:40 rburton1: so is meson + a few dev-years of work to port core packages going to make building YP build 2x faster and debugging less painful? :) Sep 08 14:23:10 vmeson: oh i doubt it! Sep 08 14:25:00 you know that we spend ~20% (?) of the time on auto* hell, right? Anyway, you might write a short summary email to oe-core or some other list. I'd read it. Sep 08 14:26:30 yeah i know that we spend far too long in configure Sep 08 18:23:24 anyone tried pyqt for qt5 yet? Sep 08 19:04:42 Crofton|work: someone who i can't recall said they use it Sep 08 19:05:19 hmm, I do not think there is arecipe Sep 08 19:05:24 need to go ride then cahse Sep 08 19:05:56 Why do I always end up riding at the hottest part of the day? **** ENDING LOGGING AT Fri Sep 09 02:59:58 2016