This is DEV NEWS

Newest items at the top All the cool tidbits from Discord that you should know.

Index

• Build All Script (build the world)
• Rebaser - sung to Pixies DEBASER

---

Jan 2024

BUILD ALL

[fenrock]

I've add a ./build.sh -a option that will build all platforms.

This is for testing your changes locally to see if they will break any platform. Usually you won't need to bother, but for anyone doing large changes, this will be handy to double check before you push your change.

It doesn't affect your platformio.ini file in any way, but does run a platform build which will overwrite any you previously built for your target, so if you do want to get that back, you'll have to run a normal ./build.sh -cb after the bulid-all finishes.

This works by having a new build-platforms dir, which contains skeleton files for each platform, merging them with a BASE.ini file and using that to build the platform (as pio run allows a target file to be used with -c path/to/your/foo.ini)

The skeleton files have content like:

[fujinet]
build_platform = BUILD_ATARI
build_bus      = SIO
build_board    = fujinet-atari-v1

[env:fujinet-atari-v1]
platform = espressif32@${fujinet.esp32_platform_version}
platform_packages = ${fujinet.esp32_platform_packages}
board = fujinet-v1
build_type = debug
build_flags =
    ${env.build_flags}
    -D PINMAP_ATARIV1

containing enough to define the platform when merged with the base file.

Any new platforms will need a file, they're pretty self explanatory. You can easily run multiple targets for any platform, see platformio-IEC-lolin.ini and platformio-IEC-nugget.ini for examples.

The build will take quite a while depending on your machine, about 5 mins here, as it's doing a Clean + Build for every platform.

REBASER

[fenrock]

I know this was a really simple change, and you pulled HEAD before starting it (yay!), but at the time you pushed, there was already another change against HEAD compared to when you started. I'm trying to bring the habit of rebasing before pushing so your commit should have been against that.

I'm not trying to pick on this case, but it's a really good simple example for everyone of what it looks like when a rebase hasn't happened before pushing.

ad4f5a39 commit (yours) was based on 20d5b2cf, but at the time of creating the PR, 9984e779 was in the repo for an hour, so it would be nice if you'd pulled it down and rebased your change on top of it before you created the PR.

I know in this case it was a really minor change, and only 1 small change between, but this is an exact minimal version of how we've been getting complex merge commits when people have several days between pushing, and the changes between the starting commit has lots of similar merges because noone is rebasing, so we end up with N-complex merge commits all hitting the repository.

Hopefully I'm conveying that I'm really happy the change happened, and I'm really not trying to sound over dramatic on such a small change, but I wanted to use it to show how we've been getting issues with our git history in the past.

There's a pin with the new guidelines in the channel, and I've put a shell script that works on linux and MSYS2 (haven't tested it on mac) at https://github.com/FujiNetWIFI/fujinet-platformio/wiki/"upstream.sh"-Script-To-Rebase-Changes that would rebase your work (on any branch, even master) for you before you push your change, then you can push your change, and create the PR.