Build RRF3 issues
-
thats all fine and dandy, but the problem is you seem to think buying the hardware entitles you to some premium version of the free open source firmware which doesn't exist.
as has been pointed out he last stable release works just fine, and is tagged for checkout in git - throwing a fit because the bleeding edge isn't building over a weekend isn't gonna help the project or yourself
-
@bearer did you even read what I said. The 3.02 build doesn't even compile without fixes. I don't care about the latest dev branches. I'm talking about the whatever is considered the most stable version. Neither does 3.01, it's even in worse shape due to changes made to other projects.
-
3.1.1 does which is the latest stable. 3.2 isn't even released as a beta yet
(admittedly some are only tagged as 3.1.0 and some 3.1.1) -
@bearer ohh...so you see how the tags are all over the place.
-
no i don't; do you see ubuntu re-tagging each package when they release LTS 20.04 f.ex?
-
@bearer not going to argue. If this is the state and policy of duet, this is my last board I purchase.
-
I don't think you'll find (m)any other vendor(s) where the developer(s) will update git in a timely manor on the weekend; but you're free to make your choices.
As to what is the policy of Duet, Duet will have to answer. The state is what it is, and is likely to vary.
-
@bearer my point was the current state. I'm not asking for duet devs to fix or reply on weekends. You can defend the code base all you want. I have higher standards at my job. We have jenkins building the most recent code not even alpha, nightly, not even released or available to clients, and if there is even a single line of dependencies is broken it's fixed immediately. I understand having unit tests fail in nightly, that happens, but it should compile. Instructions for rrf3 are out of date, the tags are inconsistent, the master of canlib has commits from December which are not accounted for in any rrf3 tag except 3.02. I already said my position on code quality. I do this for a living. If someone forgets to commit something - it gets delt with. This isn't a project where anyone can just contribute. It's open source, which is great and the only reason I own the hardware.
-
I wouldn't say I'd defend the code base; there are alot of things i'd wish Duet do differently, and the current state is partially because Duet are trying to move from the way the used to version things to how some of the forum users wanted things to be versioned.
In any case; while instructions and state is not immediately obvious people of lesser skills seems to be managing so maybe the issues isn't just the code base.
At the end of the day you have a very limited development team whose priority is the vast majority of users who don't care to build the firmware themselves, a tiny fraction who get on just fine, and then the rest. Its a matter of proportional resource management.
-
@bearer as I said, i figured it out. My post was for duet devs not to get into an argument on the state of the open source software -- there are tags and branches. I already have a build with the CNC specific changes I wanted to make which are super minor, but make a huge difference for the safe operation of a CNC mill. I hope Duet will update RRF3 build instructions
-
I've updated BuildInstructions.md on the master branch.
-
-
@CaLviNx me? very mature dude. @dc42 please close or delete this topic -- I'm not interested in arguing or silly back & forth. I simply asked for what you just did -- I don't need to get into how others approach the code base.
