Re: regarding future plans for EMC

[Fred Herenius <fred-at-twonky.xs4all.nl>]

Matt Shaver wrote:
> "cleaning"
> There are too many #ifdefs. Part of the reason is that the EMC will
> (might?) compile and run on several different platforms (PC Linux, SGI,
> Windows, Alpha, etc.) and for Linux there are several versions of
> rtlinux supported as well as RTAI. If we could narrow the these choices
> down to one, a lot of the #ifdefs would go away. The problem is that,
> although 99.999% of all EMC systems are PC/rtlinux systems, there are
> (I assume) SOME users of the other platforms. Should they be abandoned?
> Should there be a streamlined EMClite (I really hate that name, don't
> use it...)? Another possible "have your cake and eat it too" solution
> would be to move as many of the conditional statements into the build
> system as possible using autoconf and automake. This leads me to...

> "plans"
> Let's see, so far I've talked to Fred & Will at NISTand Ray Henry about
> switching to autoconf and automake. I also started reading _The Goat
> Book_ (http://sources.redhat.com/autobook/). I am in over my head, but
> flailing madly to stay afloat...

Hi Matt, still afloat? ;->

Switching to automake+autoconf sounds like a great plan! Should help make
first-time compilation by new users easier and also make maintenance of
multiple platforms easier for developers. And I love to be able to _NOT_
read the install docs, just do
./configure && make && make install
and have it work too.

Which brings me to the ifdeffing. Risking stating the obvious (or the 
erroneous?), the ifdefs can roughly be placed into the following categories:
(Not the full story, but trying to keep it sortof brief)
- functionality dependencies. For example in the stepper modules, to check if
  the piece of code was being compiled as stepper module flavour X, or flavour
  Y. Lets keep it short and just say I think this can be solved differently,
  and IMO cleaner.

- hardware platform dependency. For example, are we driving a PC parport,
  or an Alpha parport. There are a few approaches to this, but I don't think
  you should rely on autoconf to handle this for you. Quick and dirty way is:
#ifdef YESYES_THIS_IS_PC_HARDWARE__AND_ECP_TO_BOOT
   handle_parport_hardware_for_a_pc()
#endif
and use this snippet every time you need to use the parport. This usually
gets messy if it's used more than a few times. Better is to define a macro
to handle the hardware dependency, and use this macro. After the cpp stage
this results in the same code as the previous method, but is easier to
maintain, since all dependencies are gathered in one .h file.
If it turns out that you need too many macros to handle these dependencies,
it might well be worth adding a layer to abstract your hardware. Abstraction
can be done without performance penalties (and seeing the way IO is currently
handled I suspect it won't be a penalty). For a small and simple example of
this sort of abstraction check out the i2c kernel source.

- software platform dependency. Are we using rtlinux or rtai? Are we on hpsux
  or linux? This last example it not an issue with emc I suppose, but it's an
  example. This can all be handled with automake + autoconf.

> "active"
> This is the hardest one. For myself, before I could even begin to make
> any changes, I'd have to really understand the existing code. As I am
> only a beginning C programmer, that's a lot to swallow... Perhaps the
> thing to do first is to write better (more?) documentation.

Yes please :->  Documentation would greatly help.

Fred