On 12/21/13 23:19 , David Bagby wrote:
>
> I believe the latest unified binary stuff is now in the LCNC
> "unified-build-candidate-3" branch:
> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/unified-build-candidate-3
>
> I think that the UBC branch is what accomplishes #3 of the todo list for
> 2.6.
The ubc3 branch does #2 on the todo list, and a bunch of other things
that are not on the list. It requires #3 in order to be deployable to
users.
>>> The file I referred to notes that we hoped to see (post merge) some
>>> additional top level config branches. for example:
>>> linuxcnc/configs/x86/
>>> linuxcnc/configs/x86/PC
>>> linuxcnc/configs/x86/SIM
I'm glad we agree that the configs structure should be tidied up and it
should be easier for users to find the configs they care about. We came
up with slightly different structures, but we're all headed in the same
general direction.
>>> Would you consider using this structure to hold the x86 configs you're
>>> reorganized?
>> It seems reasonable. I would imagine that there should be a level
>> of sim that works on any architecure to mitigate maintenance of
>> redundant configs:
>> linuxcnc/configs/sim
> That sounds like a reasonable improvement to me.
> I admit to having been BeagleBone focused at the time and probably
> didn't think about the Sims as much.
>> The config-cleanup has already changed hundreds of files and
>> directories and has some residual broken configs -- but if the
>> 2.6 release manager endorses for 2.6 I would work on this.
> When the UB stuff and ARM support was discussed last June in Wichita,
> the eventual consensus was to include UB in 2.6 and let stuff built on
> top of it go into 2.7.
> Since the non-x86 dir structure I mentioned went in the MachineKit
> branch, it probably won't show up until after 2.6.
> However it seems to me that adding/using a compatible dir structure for
> 2.6 will make 2.7 easier re the non-x86 configs.
> There is significant non-x86 LCNC use today and non-x86 configs just
> don't fit very well into a "flat all x86" config organization structure.
The new config structure in master is not x86 specific. As Dewey
pointed out, for example, the sim configs run on all linux systems,
independent of CPU architecture. The non-sim configs are also not tied
to x86, except by the coincidence that linuxcnc itself (prior to ubc3)
is tied to x86.
Any machine architecture that has a parallel port should in theory be
able to run the configs/by_interface/parport/* configs, and any
architecture that supports PCI or EPP should be able to run the
configs/by_interface/{general_mechatronics,mesa,pico} configs.
David said in another email:
> In short, we adopted a basic structure of
> linuxcnc/configs/<architecture>/<platform>/<hardware_interface>/<machine_config>
>
> Thus the Shapeoko configs I created for my bench test platform are in
> linuxcnc/configs/ARM/BeagelBoneBlack/K9/Shapeoko
I think if you drop the '<architecture>/<platform>' part, your structure
is nearly in alignment with the structure we worked out for 2.6. I hope
that i've explained why i dont think architecture or platform is a
useful level in the configs organizational hierarchy.
The Shapeoko config would fit neatly into
configs/by_machine/K9-Shapeoko/BeagleBoneBlack-PRU-RAMPS.ini (or
whatever your particular interface hardware would indicate), and an
example of how to use the BBB PRU (independent of any particular machine
plugged in to it) would fit neatly into
configs/by_interface/BeagleBoneBlack-PRU.
Does that make sense? Seem reasonable?
--
Sebastian Kuzminsky
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
