Contribution Story: Adding an Option to Doxygen

I use Doxygen to generate documentation for a library I maintain, libSDL2pp. One day I’ve been looking the generated documentation through and my eye was caught by what supposed to be my email address, which was obfuscated beyond recognition. Email obfuscation is absolutely not what I wanted, and Doxygen had no way to disable this behavior, so I’ve decided to implement one.

Here’s how it looked in the generated HTML:

Code (formatted for readability):

Python 3.11 in FreeBSD Ports

A month ago I’ve landed Python 3.11 (alpha2) in FreeBSD Ports tree. This is a continuation of my past work on Python 3.10 support, and likewise, it allows curious ones to play with the upcoming release, maintainers to prepare their ports and developers to make sure their code is compatible with the language changes. I’d like to share some details on latest Python support in FreeBSD and the story of porting Python 3.10.

Packaging Friendliness: Compiler Flags to Avoid

It is tempting to enable some (generally useful) compiler flags such as -Werror and -march=native in you build by default (such as to discover more problems and generate more efficient code), however in practice these flags may lead to packaging problems instead.

Writing Huge Posts Is Hard

The portability ABC activity has kind of stalled, most probably because I’ve attempted to bite off too large a piece - that is, to write too huge article at once, in two languages on top of that. There are two such articles in the drafts, and the amount of work needed before posting them is demotivating. So I’ll try to switch to smaller posts now.

Apart from that, I’m thinking of a new name, as the topic is actually closer to packaging friendliness than to portability. Something like “A Guide To Portability And Packaging Friendliness” (GPPF) maybe?

Portability ABC: project naming

Surprisingly, portability/packaging issues may be introduced to a project long before the first line of code is even written, merely by a bad name choice.

Make sure the name of your project is clear, unambiguous, unique and compatible with packaging, otherwise the package or files installed by it are likely to be named differently than you’ve intended (to avoid name conflicts, comply with packaging policies, or just because of misunderstanding). This, in turn, causes trouble for users locating and running your software and breaks automated tools (such as new upstream release checkers and security vulnerability reporters). In addition, these changes are likely be different in each other repository, which complicates distro migration and hinders interoperability, portability of dependent software and usefulness of documentation.