Hello, I will try to give an honest answer, however I am sure that as a Machinekit organization maintainer, I am liable to a tinted viewpoint.
Firstly, from your post I am not sure if you are talking mainly about the monorepo at github.com/machinekit/machinekit <http://github.com/machinekit/machinekit> or the separated repositories mainly in github.com/machinekit/machinekit-hal, <http://github.com/machinekit/machinekit> github.com/machinekit/machinekit-cnc <http://github.com/machinekit/machinekit> and github.com/machinekit/emcapplication. <http://github.com/machinekit/machinekit> But the fact is that the monorepo was deprecated and is no longer maintained or developed on. The core of development will be in Machinekit-HAL plus few connected repositories based on the momentary need and community contribution. The Achilles' heel is the documentation. The documentation is terrible. Everybody can see it. It would be great to get it to a better shape. But that would actually mean to completely rewrite it. Because I don't think there is a chance for salvaging it. I also think that there is a more pressing task in need of completion. That is the CMAKE port I am currently working on - it is going a lot slower than I would like because it is connected with restructuralizing of the codebase tree (which is completely insane at the moment), but it will - I think - allow to shed the dependency on Debian based distribution for bigger pool of GNU Linux ones. You may think that it is counterproductive to focus on development when the documentation is in the state in which it is - but one has to remember that Machinekit (all of its repositories) is mostly used in companies and company specific products. Jan 4, 2021, 23:24 by [email protected]: > I have spent the better part of a couple of evenings trying to get it to run > from sourcecode. > > And i can tell you, its only because i really know my way around linuxcnc as > a devops i actually managed to get anything done. > > But here is some notes. > Repository / prebuilt packages > - They work. > There currently are multiple repositories. The old ones are the deb.machinekit.io are in process of deprecation (as they are hosted on private server of long gone Machinekit member with no change of getting access). The new ones are hosted on Cloudsmith service: https://cloudsmith.io/~machinekit/repos/ Specifically: https://cloudsmith.io/~machinekit/repos/machinekit/packages/ - for common dependencies https://cloudsmith.io/~machinekit/repos/machinekit-hal/packages/ <https://cloudsmith.io/~machinekit/repos/machinekit/packages/> - for Machinekit-HAL https://cloudsmith.io/~machinekit/repos/emcapplication/packages/ - for EMCApplication https://cloudsmith.io/~machinekit/repos/mksocfpga/packages/ - for MKSoCFPGA > > - But they are missing machinekit-dev package. > - This is important if you wanna develop anything without needing to setup > from source. > That's should be working, respective not the machinekit-dev one, as that is from the monorepo, but the machinekit-hal-dev one. > > Building my own packages > - The build tools for building a developer environment. Containers is great, > but its really overcomplicating the crap out of it. It was way easier to just > go grab the commands out of the docker scripts and run it locally. > I like them. So this may be on me. They help me keep things clean. Of course to just run the scripts locally should be also possible. > > - The dependency tree disaster.. there is so many package that is in use, and > so little documentation. I started a list of packages i needed to get > installed before even running configure.. its in the ball park of 60.. and > many of them are outdated, removed, or just not possible to get working on a > debian 9 or 10 installation > The easiest way is to just use the mk-build-deps debian script. This is also the reason behind the container's usage - it is just so easy to delete the whole FS when one is done and no longer wants to have it installed. And all of them can be currently installed. > > Splitting machinekit into two repositories. > - Well this is a case of the road to hell is paved with good intentions. > - Why.. well from a programmers standpoint i can understand it being > smaller chunks to manage, but from the point of view of the user its quite > hard to grasp all the concepts that has been applied without go digging into > scripts, support stuff and other things the "user" usually don't really care > for. > The idea behind it is to have sometime in the future a ready-made container with Machinekit-HAL+EMCApplication+whatever else or just to install the lowest package in the dependency tree. Like the EMCApplication. (It's currently little convoluted because Debian packaging leaves a lot to be desired and currently on its own cannot solve a dependency tree of multiple projects going at different vectors. So you need for EMCApplication to install older version of Machinekit-HAL and such.) > > In the end i got all the packages built with no fuss, and was gonna runt the > ol' dpkg -i machinekit-hal - and well.. what do you know.. it requires more > package dependcies.. on packages that doesnt even exist anymore .. like > "python3-avahi" .. That now makes the whole effort useless.. > Python3-avahi is available. I know because I spend multiple hours building it and other packages. https://cloudsmith.io/~machinekit/repos/machinekit/packages/?q=python3-avahi > > And final thought.. the prebuilt packages on archive is version 0.2, when > building my own packages i made a jump to 0.4.. when going to git and looking > in the branches.. well what do you know.. no 0.2 to be found or any other > branch... > The 0.2 is in the old deb.machinekit.io repository. I cannot do anything about it, I don't have the keys. That's the reason why the Cloudsmith repo was created, here I can give access to all active Machinekit organization's members. > > Please at least follow some.. "rules".. make sure the compatibility packages > can be built, like if its gonna be a split of source code.. make sure there > is coherent documentation on how to compile it.. When compiling i get the > machinekit-dev package btw, why isnt that on archive?! > Again, you are probably compiling the monorepo. Or some older version of Machinekit-HAL. There should be no machinekit-dev package anymore. > > I'm working as a senior devops / project manager in my day to day.. I will > happily pitch in with some organizationl chops and hand pointing if it would > help the project.. Also happy writing documentation. I basically already have > for my experiments with this. > Of course, any and all help is appreciated. The best space for discussing this is the Github issue tracker. Based on the area either in Machinekit-HAL, EMCApplication, Machinekit-CNC, Machinekit-docs or any other. Cern. > > > > -- > website: > http://www.machinekit.io> blog: > http://blog.machinekit.io> > github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > [email protected]> . > To view this discussion on the web visit > > https://groups.google.com/d/msgid/machinekit/b83674b1-a8fc-4c28-bb06-62cb0d754e53n%40googlegroups.com > > <https://groups.google.com/d/msgid/machinekit/b83674b1-a8fc-4c28-bb06-62cb0d754e53n%40googlegroups.com?utm_medium=email&utm_source=footer>> > . > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/MQ_29M4--3-2%40tuta.io.
