I managed to delete your reply to this email. I'm copying the text from
the sf archive, but replying to myself, so your client's threading may
get messed up. ;(
>> Since EtherCAT libs will be missing on most systems, library detection
>> would need to be added configure.in, and driver build made conditional
>> in the Makefiles.
> I've just added a config check for this. It works with the deb install and with
> the manual install of the master.
A few comments:
- The configure.in check might be better done using AC_CHECK_HEADER
(look for other examples in the file)
- 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!
- Additions of the string 'emc' are discouraged.
- In your checks for Module.symvers, I'm wondering if failure to find
the file but CONFIG_EMCEC=m will cause a build failure?
- I personally would have left the EtherCAT Debianization materials out
of the LinuxCNC source. See below.
- You've added libexpat1-dev as a build requirement in
debian/control.in, but I don't see corresponding header or lib checks in
- I'm not qualified to comment on the driver's C code. Hopefully
someone else can step in.
> The later however may produce some warnings
> about missing symbols as the Module.symver file will not be installed by "make
Warnings while running ./configure, or during the build?
> and a small hack by symlinking the ecrt.h is required because I think
> it's a bad idea to add /usr/include to the include path for module building.
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.
> For the LinuxCNC dist based on Ubuntu it should be easy to integrate the
> ethercat master debs into the repos. The question is if the debian directory
> I've created is ok for that or if it needs some improvements (support for
> xenomai, newer kernels...) and, if so, how to test.
Yes, I'd say ethercat debs should be built separately and distributed
with our kernels.
The etherlab site says ethercat can run on all kernels the RTOS branch
supports: vanilla, rt-preempt, Xenomai and RTAI.
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.
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.