That’s not how software projects work. Each project has its own build system, its own instructions for turning the sources into an executable. If you don’t follow those instructions, you’re choosing to make things difficult for yourself.
I’m not going to de-organize the project and rewrite all its internal infrastructure just to make it easier to build with proprietary tools it was never intended to be built with.
In Windows, there are two easy ways to compile it: WSL or Docker. Pick one.
It already does. One of the first steps in setting up the build environment is to download and install DFPs directly from Atmel, which make dfp helpfully does for you.
Git doesn’t have revision numbers like r817. It has commit IDs, like bc0b4625a1618d9322ea6a5f0bb402f8ddc0aad6 (or bc0b462 for short). I’m not super happy about it either, but it’s what people use. Regardless, the repo currently has 1178 commits in it, and a lot has changed since the last bzr version.
To do things in a more git-like manner, the version string is instead derived from the most recent release tag… potentially with extra info at the end to indicate how many commits since the tag and whether the repository is in a clean or dirty state. Like, yesterday’s release was tagged r2023-12-03, but if I were to add 158 commits and build in a dirty repo with uncommitted changes, the git describe tool would report the version as r2023-12-03-158-g0abcdef-dirty. This is then shortened somewhat to produce the version string used by Version Check mode: 2023-12-03+158#1. I’m still undecided whether it should include the rev short-hash in builds like that, but at the moment it omits that part. Official releases have a tag though, so it’s just the date with no +N or #1.
Anyway, the short revision numbers are gone because Linus Torvalds was feeling spiteful and contrarian in 2006 when he created Git.
Compiling is one thing and another thing then trying to code. Before “r817” all we had to do to update Atmel project was to drop new version files on top of old… . Now in Github style You added directory patches inside files like “fsm/ramping.h” before was just “ramping.h” and then all files are in same directory … now I have to rewrite every f single files patches… and i did and it does not compile anyway :DD
I recall you putting everything into one directory and then updating individual files one at a time… but that was never a supported way to build the code and it’s not how most software projects work.
Weren’t you doing that just because Launchpad’s tarball feature was broken and bzr didn’t work very well in Windows? Git has much better Windows support. All you have to do to update your local copy is git pull origin trunk or click the “pull” button in an IDE. Most of them have Git support these days.
Regardless, it’s not going to work with everything in one directory. Half the files have the same file names but in different directories. The directory structure is a semantically important part of the build.
So… install the latest debian or ubuntu in WSL. Run a couple apt commands to get build dependencies. Git clone the repo. Run make dfp. Then run make. That’s how to build it in Windows. That’s also basically how GitHub’s Continuous Integration system builds the code after each commit, so you can be pretty confident it’ll actually work.
The release file will include all the various hex files, unzip it on your phone and then use ZFlasher to select the one you want to flash to a particular light.
There may be a simpler way, but I’m not the dude who can tell you what it is!
This would clarify another regular question on reddit, so the only challenge remaining is to try to get reddit to RTFM… (and stop posting links to out of date resources).
I find the manual is about the only source worth using anymore… Not knocking the work people put in making the diagrams, but with the continual evolution of A2 it’s gotten much harder to find the current one.
It took me a month to figure out what I was doing just locating the hex files on GitHub - I’m way out of those loops anymore, but it’s not too difficult.
