> Date: Mon, 8 Jul 2013 16:11:40 -0500
> From: jep...@unpythonic.net
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] discuss: packaging HAL separately
>
> IMHO This proposal has multiple goals packed into a very short summary.
> Since I have not read a rationale for this proposal, I hope I am not
> confused about the goals.
>
> Anyway, to me it breaks down into at least 4 things:
>
> 1. The "machinekit" name
> 2. New features in RTAPI and HAL such as zeromq
> 3. Source code organization and possibly release management
> 4. Distribution packaging
>
> (note: when I write 'hal' below I generally mean to indicate 'rtapi and
> hal')
>
> Let's go from back to front:
>
>
> 4. Distribution packaging
>
> To serve the needs of people with storage-constrained systems, we should
> clearly consider patches which split the current monolithic linuxcnc.deb
> package in a way that serves them better. I am +1 on this idea, though
> as far as I know there are no proposed patches as yet.
>
+1
> Also it's not 100% clear to me that hal vs non-hal is the right split
> point. For instance, without looking I assume that it is the UIs that
> create the greatest foot print in terms of installed size with
> prerequisites. (for instance, stripped of debug information, milltask
> 200kB and motmod is 100k) On the other hand, halshow is a tcl/tk app so
> if the packaging split is hal vs linuxcnc then the hal part would still
> pull in tcl tk.
>
> (related: configure flags to disable stuff at build-time are also good
> for many of the same reasons and I'm +1 here too if someone does the
> work)
>
Originally classicladder worked this way - you compile flagged out the GUI.
we could have two HAL packages - core and GUI or as you said compile
flag the GUI packages.
> 3. Source code organization and release management
>
> The primary user and driver of new hal features is LinuxCNC. As a
> result, I personally am happy that the LinuxCNC release cycle drives the
> hal release cycle, and don't experience any pain resulting from
> hal and linuxcnc living in the same git repository with a single release
> branch managed by the same release manager. At the present time I do
> not see a reason to change this. This questiom would merit revisiting
> once there are substantial non-LinuxCNC users of hal. As a result, I am
> -0 on this idea right now but realize that it may change in the future.
>
I wonder if this is the chicken and egg thing.
Linuxcnc is the primary user and driver of HAL because it isn't separate.
We also don't promote HAL's use outside of linuxcnc.
If your not interested in CNC machine control you probably won't ever find HAL,
especially with the name HAL - that's pretty generic and cryptic.
>
> 2. New features in RTAPI and HAL such as zeromq
>
> These need to be reviewed independently on their merits.
True.
I think the reason for inclusion is it makes 'independent' HAL
considerably easier to use for networked projects. The alternatives are
to add NML to the 'independant' HAL or let the users develop their
own way.
I personally think we should promote HAL on it's own and adding the
zeromq stuff seems to make it a well rounded package.
>
>
> 1. The machinekit name
>
> I prefer to keep the name LinuxCNC related, such as "LinuxCNC HAL".
> I imagine other people will have different names to propose, and I'm not
> sure how best to settle it.
>
I really don't have a strong opinion. I will point out again though that HAL
is not very descriptive and is used elsewhere in computer terminology.
Machinekit does give me the impression that the package is used for building
machines. HAL is a computer from Odyssey 2001... :)
>
> All items but #4 (depending on RM's opinion) look like post-2.6 so I'd
> also prefer to punt them down the road until 2.6 is on our users'
> systems.
>
> Jeff
Not sure what you mean be 'punt them down the road', if you mean discussion
- I think the guys working on it would like to know if they are driving down the
road to the right general area .
If you mean all this should actually merge after 2.6 - then I agree.
Chris M
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
