RE: regarding future plans for EMC

["Pete Cook" <pete.cook-at-alltracorp.com>]

Could someone give a clear description of the pieces parts of EMC?
The reason I ask this is because I am curious as to how much of of EMC I
would need to rebuild to make another module for different physical
hardware. I understand that there is the realtime part of EMC and the
non-realtime portion. How tightly or loosely are they coupled?

Pete
>
> 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
>