~BitBun~ @BitBun@raru.re

Not dead, busy with work. Trying to get some changes reviewed before everyone peaces out for the holiday. ;_;

Stay safe y'all!

My first run of `toolchain-repo-upgrade` completed!

There was only one issue, a patch file I had created for clang 10 no longer applied, but luckily clang 11 no longer needs this fix - so I just removed the patch step.

Here are some use cases.

If they want to build all my projects with whatever binaries they happen to have installed on their system:

```
git clone http://this_repo .
mkdir build && cd build
cmake ../
make all
```

If they want to build all my projects with the versions of binaries that I am using to build with:

```
git clone http://this_repo .
mkdir build && cd build
cmake ../
make toolchain-upgrade
make all
```

If you are maintaining the repository, and you want to attempt to upgrade the toolchain to new versions (this makes changes to the repo through submodule checkouts):

```
git clone http://this_repo .
mkdir build && cd build
cmake ../
make toolchain-update
make toolchain-repo-upgrade
```

My expectation is that some automation will do that last one. It makes changes to the repo, tests the changes, then pushes to update everyone's submodules on the next pull/rebase. If something doesn't build, it will require manual action to unstick.

I'm considering in the future having this logic be a bit smarter. Maybe doing something like reverting packages which fail building and leaving packages which succeed (so that it isn't all-or-nothing). But that requires more careful thought.

So I added three new targets to the build system this weekend:
* toolchain-status
* toolchain-update
* toolchain-repo-upgrade

`toolchain-status` is used to show the current status of the active toolchain. This means whether or not it is up-to-date with the defined toolchain specifications.

`toolchain-update` does a fetch on all toolchain-relevant submodules, and then checks to see if there is a new latest version to target (reporting it if so). This is how we learn that upstream repositories have new releases for us to consider using.

`toolchain-repo-upgrade` is how you actually target the new upstream releases. This basically attempts to `checkout` the new released versions of each submodule, and then tries to build everything. If building (and eventually testing) succeeds we assume the new packages are good. Otherwise, on failure, we revert the packages by checking out the original versions of the submodules.

So, you could imagine some automation:

```
make toolchain-update & make toolchain-repo-upgrade
```

Which runs continuously and only alerts someone if a repo-upgrade fails.

Okay, I am actually making progress on my build system today. (I took last weekend off.)

I was in the middle of a refactor, changing my directory hierarchy for the build scripts. I also was planning on adding new targets to the system (toolchain-status and toolchain-update).

I'm definitely liking the new structure, but I think I may need to change some function names as well. Tomorrow I will add my unit tests back in for CMake code. And I think that'll be my next commit.

Originally I was planning on having my first officially supported target be Python3-related, but I think I need unit testing for some of these helper functions I'm creating.

Sometime soon, I will actually add a useful target that produces an executable. ;_;

Trying to be productive, end up watching vtubers for a few hours...

Let me try this again lol -

Speaking of spooky

https://www.youtube.com/watch?v=NYc5AoVq_2k

HAPPY SPOOKY DAY!

Was gonna try to save on vacation days, but I really need to take some time off. Gonna take some time off in a few weeks.

Okay, I can feel that this next change is going to take a long time... I probably won't be done with it for another several weeks. -_-

Struggling to make progress on my projects today. -_-

Happy weekend everybody!

Weekend! Time!

This weekend, my goal is still to support Python3 as a build target. I added language modules for Python3 (so that I can do `project(Name LANGUAGES Python3)`), and I created some functions for creating Python3 build targets (modules, binaries, tests, etc).

Well... They don't actually do anything other than copy files. What I want the build step to do is to run the `compile` command on these files, as sort of a syntax checking mechanism. That, to me, represents a "build" step for Python3 targets.

As for tests, I think to start I'll just use the provided `unittest` module. After I get that working and integrated with CMake, I'll probably upgrade to pytest. The goal here is to be able to easily create unit tests for my modules.

All of this is kind of lame - I really want to use a different language for my utilities, I just haven't decided which language yet. Adding Python3 support is acting like a test for what I'm going to do to support other languages. I know what I'll do for C and C++, so those aren't very interesting.

I'll probably add support for a few languages just to get the hang of things, and then I'll narrow in on a specific language for my utilities. It's not desirable to have a scripting language for my utilities.

In college, when I didn't give a shit about my website except for being a resume, I used Wordpress.

I'm still suffering for this. Really wish I would've just spent a little time and used a static site generator or something.

Can't wait to be fucking rid of it.

I bought the special edition Prinny game pretty much just for this.

Korone reads the English word for "pipe" as it would be pronounced in Japanese: http://www.youtube.com/watch?v=_pid5tfoOy8&t=75m32s

At least it is much easier to use now than when originally introduced, but I still happen upon strange cases where I struggle to understand why it isn't allowed.

constexpr problems