Hi John, thank you for your hints. Here the current status:
> - The configure.in check might be better done using AC_CHECK_HEADER > (look for other examples in the file) This is right. But I need the path of the ecrt.h file, because I have to symlink it to the ethercat hal driver source directory, if the master is installed manualy: > Are you saying ecrt.h is installed into /usr/include by the EtherCAT > build system, and that file must be #included in module sources? Hrm. Yes, exactly this is the reason for the symlink hack. I will be thankful for a better solution. One way could be to use AC_CHECK_HEADER and then check the used include path for ecrt.h. But I don't know how to do this. > - You might want to clean up the commit history for the sake of git > bisectability. d1365ae, 57abb64, and the first hunk of 761521e could be > squashed together (and the second hunk of 761521e could be separated). > I just spent 40+ hours with git rebase -i fixing this sort of issue in > our UB/RTOS branch; don't make my mistake! I have tried to clean up my commit's in a meaningful way now. > - Additions of the string 'emc' are discouraged. I've renamed all emcec stuff to lcec. > - In your checks for Module.symvers, I'm wondering if failure to find > the file but CONFIG_EMCEC=m will cause a build failure? > Warnings while running ./configure, or during the build? If Module.symvers is missing the HAL component will be build sucessfully but there might been some warings during build. > - I personally would have left the EtherCAT Debianization materials out > of the LinuxCNC source. See below. I have removed it and will create a new repos for it. > - You've added libexpat1-dev as a build requirement in > debian/control.in, but I don't see corresponding header or lib checks in > configure.in. Oops, it was just a mistake. Should the missing of libexpat1 lead to disabling the ethercat hal driver or better fail the configure process, if the master files where detected previously? > You've built your driver for the LinuxCNC master branch, which supports > RTAI. On Lucid, EtherCAT supports the linuxcnc.org RTAI kernel v. > 2.6.32 out of the box. I'm not sure the official status of support for > master on Precise, but EtherCAT does not support 3.5.7 drivers out of > the box, which is what Seb runs on his buildbot. It doesn't look that > tough to update, from what I saw, but there're a few things to figure > out, like what happened to the PIO stuff in linux 3.5. I could try to get the stuff working on 3.5.7 with RTAI, but need some time for this. I try to setup a test env. What will be the plan for Precise? Which Kernel Version? Which RT? > If you wish to port your work to the UB/RTOS branch, I'd want to look at > building the ethercat package such that runtime/userland parts are > packaged separately from kernel modules so that a host running e.g. > Precise can install separate module packages to match each of its > installed kernels (my dev machine, for example, has vanilla, RT_PREEMPT, > Xenomai and RTAI kernels installed all at once). This may turn out to > be more effort than it's worth (doing it for our RTOS branch was very > difficult), but if it turns out to be easy, it'll save headaches. From > there, our UB kmodule packages (which don't exist today ;) would depend > on the matching ethercat kmodule package. Yes, I like. But I don't know what that means at the moment. I'm currently not familiar with UB. Where could I start? Regards, Sascha ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
