Hello LinuxCNC brain trust. I've been working on and off to adapt LinuxCNC to compile for the OpenEmbedded Yocto project (for the unfamiliar it's basically a tool to create extremely limited, focused Linux distributions for embedded purposes).
I've actually got a working OpenEmbedded recipe that can cross-compile and run LinuxCNC along with Axis - but I had to do a few dirty hacks to get there and I was hoping for some input. One major hurdle was that paths to certain executables get hard coded *at ./configure time* instead of using the PATH / env at runtime. A few examples: ps, pidof, grep, awk paths get templated in when ./configure is run: https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/linuxcnc.in#L43 Python executable path is set by ./configure here: https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/linuxcnc_info.in#L155 Hardcoded shebangs are also inserted into files all over the place by the Makefiles: https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L521 https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/Submakefile#L34 These paths are all determined and placed into template variables in configure.ac here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/configure.ac#L830 This kinda-sorta seems to work as long as the system you're building on happens to exactly match the filesystem layout of the one you're building for (building for a Debian target on a Debian system). It essentially explodes the whole world if you're cross compiling from one system (Debian) to one that stores executables in different places (Yocto embedded). I suspect (but haven't checked) that the Python shebangs also prevent the usage of an active virtualenv for users who work that way. I was wondering if anyone knew the history behind this behavior and could point out a reason it's done that way? Right now I've been working around it with a large .patch file that replaces compile-time path templating with "#!/usr/bin/env" shebangs for the respective executable but it seems like some package maintainers frown on this type of solution because they want to guarantee that things are always run using the system installed tools (not a possible /usr/local installation of Python, for example) Best, Peter _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
