#xmake — Public Fediverse posts

Замена STM32CubeIDE и переход в среду VSCode для Embedded-разработки

Бесплатных IDE для разработки микроконтроллеров не так уж много, а их интерфейс, основанный на Eclipse, вызывает у меня только страдания. В итоге разработка превращается в постоянное переключение с VSCode для редактирования кода в CubeIDE для его сборки и отладки. Но почему бы не собрать все инструменты в VSCode в едином расширении, заодно подогнав автогенерацию проектов под стиль компании/личные предпочтения? Об и будет моя первая статья. Привет, Хабр!

https://habr.com/ru/articles/1020160/

#xmake #cubeide #stm32 #vscode_extension

People often complain that my coding style rule that you should not use abbreviations gives overly verbose code. I normally reply that:

• Code is written once and read many times, optimising for reading is better, and
• People have different preconceptions about what abbreviations may mean.

Today, I found a great example, in the #xmake codebase. The function that checks whether a code snippet in a C-family language compiles has the following set of options to pick the languages:

cc|cxx|mm|mxx

You will note that most of these are file extensions that the compiler will support with a default language inferred from the extension:

• cc: C++ file.
• cxx: C++ file.
• mm: Objective-C++ file.
• mxx: None.

In contrast, xmake treats them as:

• cc: C
• cxx: C++
• mm: Objective-C
• mxx: Objective-C++

If you see in the code sourcekind="mm", you would be forgiven for assuming that the code should be assumed to be Objective-C++, because that's what clang or gcc will assume a .mm file is.

It adds almost nothing to the verbosity of these to treat c as C, c++ as C++, objective-c as Objective-C, and objective-c++ as Objective-C++. Yet a person who sees sourcekind="objective-c" will be able to understand that the code should be treated as Objective-C with zero additional context.

People often complain that my coding style rule that you should not use abbreviations gives overly verbose code. I normally reply that:

• Code is written once and read many times, optimising for reading is better, and
• People have different preconceptions about what abbreviations may mean.

Today, I found a great example, in the #xmake codebase. The function that checks whether a code snippet in a C-family language compiles has the following set of options to pick the languages:

cc|cxx|mm|mxx

You will note that most of these are file extensions that the compiler will support with a default language inferred from the extension:

• cc: C++ file.
• cxx: C++ file.
• mm: Objective-C++ file.
• mxx: None.

In contrast, xmake treats them as:

• cc: C
• cxx: C++
• mm: Objective-C
• mxx: Objective-C++

If you see in the code sourcekind="mm", you would be forgiven for assuming that the code should be assumed to be Objective-C++, because that's what clang or gcc will assume a .mm file is.

It adds almost nothing to the verbosity of these to treat c as C, c++ as C++, objective-c as Objective-C, and objective-c++ as Objective-C++. Yet a person who sees sourcekind="objective-c" will be able to understand that the code should be treated as Objective-C with zero additional context.

Good news:

I've tracked down the commit that can be applied to #xmake 3.0.0 to fix it.

Bad news:

Apparently 3.0.0 had so many regressions that they aren't going to do a new release for a while yet because they want to fix them all.

And thus, hopefully, another project learns the value of putting out a call for testing before a major release.

Good news:

I've tracked down the commit that can be applied to #xmake 3.0.0 to fix it.

Bad news:

Apparently 3.0.0 had so many regressions that they aren't going to do a new release for a while yet because they want to fix them all.

And thus, hopefully, another project learns the value of putting out a call for testing before a major release.

I really want to like #xmake, but when it deduplicates positional compiler flags added with `add_cflags` (even if I set `force = true`) because it doesn't know what they do, it's hard not to scream at it.

Simple rule of thumb: if you don't know what something is, don't modify it.

I really want to like #xmake, but when it deduplicates positional compiler flags added with `add_cflags` (even if I set `force = true`) because it doesn't know what they do, it's hard not to scream at it.

Simple rule of thumb: if you don't know what something is, don't modify it.

#xmake https://xmake.io completely removed the hassle and fear of starting a new C++ #cpp project for me. It’s a delight to use (Lua), the defaults are sensible, package management is a breeze (xmake’s own xrepo, Conan, vcpkg), and it can generate project files in other formats, like cmake, Visual Studio, Xcode.

#xmake https://xmake.io completely removed the hassle and fear of starting a new C++ #cpp project for me. It’s a delight to use (Lua), the defaults are sensible, package management is a breeze (xmake’s own xrepo, Conan, vcpkg), and it can generate project files in other formats, like cmake, Visual Studio, Xcode.

#xmake keyboards

#xmake print

#xmake bike

#xmake print

#xmake bike

#xmake keyboards

#Xmake 2.6.1: Supports Rust and C++ mixed compilation

Announce
https://tboox.org/2021/12/03/xmake-update-v2.6.1/

Ok, wow! After seeing this (https://github.com/xmake-io/xmake/wiki/C-and-Cplusplus-build-system,-I-use-xmake) I was very tempted to try out #xmake. So to do so, I replaced meson with xmake in cppfetch.

And the results: I love it, I really do. It can be a tad confusing, especially because errors in xmake.lua aren't really explained the best, and rarely does it ever tell you what the actual issue is.

However, despite that; my xmake configuration is much smaller than meson's configuration, and it's so much more readable!