Build RRF3 issues
-
@kazolar if you don't mind not to use the latest version, then easiest is to use the tag function in github to get a working version: take tag 3.1.0 from every project.
Go to github into every project, choose the tag button, and download the zip file of the 3.1.0 tag version. Unpacked, the projects must be renamed to be without version info, before importing them into Eclipse.
I have not tested it, but RepRapFirmware tag 3.1.1 may work with the other 3.1.0 tagged projects. 3.1.1 has mainly bugfixes for SBC, so if you use SBC, it may make sense.
-
@JoergS5 I am not using an SBC, I got 3.02 to work -- but it's rather baffling that what is in git is not compilable. I get the idea of work fast and break things, but git for RRF3 is broken. Changes which are in CANLib were not applied in other branches, I don't know how this is a functional production environment.
-
@kazolar most branches are development branches with continuous changes. I share your experience that often the current state is that something brakes (a thread reported problems with templates now, this is something I experienced also). The only solution without wasting time which I know is to use the tags. The version 3.1.0 is sufficiently new for me.
If you use the master branches (will be renamed to main, https://github.com/github/renaming) , I expect that there will be no broken things. But the master is version 2.05.
BTW your mentioned "CoreNG from dev-3 branch" is very old. If you look in github when the last files were changed, the last change was 12 months ago. If you check CoreNG dev branch, the last change was 30 minutes ago, so the dev branch is newer than the dev-3/v3-dev branch. So if you search the newest, dev is the branch where most changes happen. This is how I decide which is the newest branch.
A last comment. I think it is not typical that so many things brake. There is a lot of new hardware coming (Duet 3 Mini, 1XD and others), that's the reason for so many changes. The new CoreN2G for example, and classes or h files to be shared and moved around. Before Duet 3 there was braking seldom. I expect that when this phase is over, it will work better again.
-
@JoergS5 with duet 3 hardware out. There needs to be a stable set of branches for rrf3, every tag for rrf3 is in some state of development. I was going through different tags for different branches, and looking for dependencies, and 3.02 is the closest to stable code that I found. I understand with the mini coming out a lot of changes are to be expected, but rrf3 should be in some final state for final hardware. It shouldn't be that what is in git latest in one project is missing a change from another project. I would understand if this was open source free project, this isn't, this is primarily for duet 3 boards which are not cheap. I have a compiled version finally, it wasn't this difficult for duet 2, it was just follow build instructions and done.
-
@kazolar said in Build RRF3 issues:
I would understand if this was open source free project, this isn't
the firmware is open source and free.
the hardware is just open source.
-
@bearer this is a distinction without a difference. Rrf3 is required for duet 3 hardware. The code for a production board should not be such a convoluted mess.
-
@kazolar said in Build RRF3 issues:
Rrf3 is required for duet 3 hardware
and it comes pre-installed and with pre-built binaries for updates; the source is not required, but its offered, as a separate free open source project.
-
@bearer the primary attraction for me to duet hardware is to be able to get the source code and make alterations as necessary. Otherwise I'd be using a different platform. Especially for the current cnc project, there many alternatives.
-
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.
-
