Build.bat
Program.sln (now Program.slnx)
Module.vcxproj
Module.csproj
Troonix makefiles niggers gtfo

>>109277623
>on Windows if you’re programming
use case?

>>109277647
>build.bat
Better not solely be invoking single threaded cl.exe without no dependency analysis like Ninja.
>the rest
Are you writing them manually or do you have template/snippets?

>>109277623
Whatever Claude uses
I don’t care about trans stuff

>>109277623
>windows
stopped reading there. what a pile of shit. just download a fucking vm or something if you have to. programming on windows is a mistake. also there's no way to NOT use msbuild if you're doing ACTUAL windows programming. if you've never had to attach a debugger and step through some fucking .net process you aint ever programmed on windows. fuck that pile of shit.

>>109277623
cmake is useful for vcpkg. you can use vcpkg without cmake (classic mode, not manifest), since libraries are just headers, .lib, and .dll files.
But vcpkg will copy the DLL files for you.
and cmake works with all the IDE's.
I use clion, but I can switch to VS studio and VS code using the same cmake presets.
>mingw
clang-cl will use msvc's STL and I hate the fact msvc has the whole VC++ redistributable dependency, but if you don't use any DLL's that use the C++ standard library (or you use the vcpkg static triplet), you can use a hybrid UCRT (dynamically link to most of the C functions, but statically link to the Visual C/C++ part), the ucrt is backwards compatible with windows 7 as long as you don't use any C functions that are exclusive to newer OS's (most people using mingw-clang are going to use the UCRT variant, and note mingw's GCC does not support address sanitizer, which is a big reason to avoid it. You should be using asan if you aren't already).
The problem with clang-cl is that you need to install msvc, which requires VS studio. I like VS studio because it has parallel stacks that's kind of useful for debugging, that's pretty much it.
Note I call it clang-cl, but technically clang-cl replaces msvc's CL AKA msvc flavored flags, but you can just use clang/clang++ just like in mingw, and it will just work with gcc/clang flags.
Also unlike msvc, clang has ubsan, which replaces msvc's RTC checks.
But if you were using cmake, the one benefit of msvc is that it just works out of the box. So non-msvc compilers require you to add warnings (and maybe ubsan). So all you need for msvc in cmake is a preset for asan and that's it, the Debug target will have sane settings.
If you are just using an editor, you can just build your code using a single file. So in vscode/clion, I believe there is a way to just have a project where you just build 1 file where it just executes the same commands as you would in a terminal. But msvc needs a dev prompt to work...

>>109277684
VS2024 does it all for me

>>109277756
>you can use a hybrid UCRT
*oh but I forgot to mention, vcpkg will not build your libraries with the hybrid UCRT.
The DLL's will link to the dynamic VCRT deps (even if the library is written in C, because VCRT contains functions like strlen).
Fixing that is tricky, you need to add a linker flag to a special vcpkg toolchain thing, but once you figure it out it, you are able to build all your libraries with any compiler / linker flags you want (without vcpkg, doing this is hell).
It will work correctly if you use a static vcpkg triplet.
You can also use vcpkg with mingw, vcpkg will copy the DLL's for you (so the binary will run), but it will not copy the mingw dll's for you (AKA pthread/libstdc++.dll/libunwind.dll you can statically link the mingw system DLL's I think, or C without threads should just work).

>>109277830
>C without threads
pthreads*
you can can easily work around this, you can use win32 or just find a library that wraps win32 around a c11 threads library or something.

>>109277756
I’m only targeting #include <windows.h> and need MSVC. I have a ”working” setup although it’s automated since it involves many steps. In Rust I could just cargo run without issues, but C/C++ is a different caliber on Windows. The steps are as follows:
> 1. Assume CMakeLists.txt and CMakePresets.json exist.
> 2. Custom editor command that runs ONCE foreach project:<command> that runs: cmake —preset debug && cmake —preset release
> 3. ’Compile and run’ by running: Ninja -C build/debug
> 4. Edit .h or .c/.cpp -> run 3. Again.
That’s how I do it in vim and neovim now, if there’s a more efficient way please let me know. I have cl.exe loaded and in path.

>Why don’t you use clang or clang-cl
Because I need MSVC’s compiler builtins, /analyze for SAL and more. Same argument goes for unix/linux where I’d use GCC over clang.

I prefer to use programming languages that don't need a build system and can gather all their dependencies from declared use of modules.
failing that, build.sh, make, cmake, meson, whatever.
autotools can go to hell, fuck autotools.

>>109278610
Some clarifications:

1. Basically à template that I can copy to current_project_dir, preferably in a custom editor command aswell.
2. Purpose is to generate compile_commands.jsons and the dirs build/Debug and build/Release
3. Is binded to a keymap.

>>109278610
> 3. ’Compile and run’ by running: Ninja -C build/debug
why not cmake --build build/debug, that way you never have to worry about whether its ninja or msbuild or makefile

File: 1770747466814746.jpg (41 KB, 491x694)

41 KB JPG

its all legacy, bloat or unnecessary deps intended to support sloppy projects.

either simple batch file (shell script) or, so much better the runtime source file format (build script). what runtime? a runtime that runs the system or a runtime that is being developed or a runtime module that is being developed.

i talked with php'tards not so long ago, they dont understand that their stuff must be build with php itself and keep on a build zoo in the source, much like another runtimes. but i basically aim for the proper and for the future.

I got filtered by cmake on windows I am too retarded to configure it. On Linux it just works but on windows there's a GUI and it asks for a bunch of locations for things and honestly I just gave up and uninstalled windows. I understand I'm a retard I just don't understand why cmake is so complex on windows, why not just one command to install it? And don't get me started on the c++ dependencies, I don't even know how to get them on windows. Last time I had to develop and app for windows/Linux/mac I just gave it to a friend and he downloaded some Microsoft thing and had to put a bunch of .DLLs into the project folder.

To be fair, his debugger worked better, but his project took 10 times longer to compile with the shitty microshaft compiler. We ended up doing all development on Linux and occasionally testing windows.

>>109279429
>why not cmake --build build/debug
Because it invokes Ninja -C directly, I just eliminate this layer (although millisexonds difference).

>that way you never have to worry about whether its ninja or msbuild or makefile
There’s a reason that Ninja is used with CMake. I don’t mess with makefiles or msbuild for (MSVC), I have a quick compile and run interface that runs from neovim/vim, and that is using Ninja as the generator (which Visual Studio itself recommends for new projects), generating a build.ninja.

Bump

>>109280698
you forgot to use the msvc developer command prompt, you don't need to path anything into cmake if you use the right terminal (most IDE's will select the msvc compiler for you).
Mingw needs DLL's (as I mentioned in a post) unless you statically link those.
the copying of DLL's on windows is solved by vcpkg (on linux you can't actually load .so libraries that are in the same folder unless you manually set the rpath to $ORIGIN, which is already overcomplicated so vcpkg decided that the default linux triplet is static)
vcpkg is better than linux package managers because you can compile your linux libraries with different flags, mainly sanitizers (linux has more sanitizers to play with than windows, but msvc has the most important sanitizer which is Asan, and it doesn't have the annoying leak check).

>>109282494
>you forgot to use the msvc developer command prompt
This, the most important thing. I use Fedora as my host, and a chinese anon told me to use MSYS2 so that I basically can port my Fedora terminal/shell config to Windows. However having to launch vsvarsall.bat along with it made MSYS2 really slow and laggy. I’m back to simple pwsh.exe && vsvarsall.bat now which works without lag and stutter.

>>109282494
This is too complicated please allow me to get libraries and tools through the same package manager thanks

Try tup or xmake. But really, just use CMake+Ninja/Make. Everything else is trash. Now, Cmake IS trash, but it's unfortunately well supported trash on operating systems that people unfortunately use, Windows that is.

>>109284075
vcpkg is a package manager that patches every single library so that it just werks with the same cmake code on every platform.
Unlike normal linux package managers, vcpkg just distributes code, you need to compile it. While on linux, it's a pre-built binary (I think you have 2 packages, the binary package and the -dev package).
For example, google uses a special snowflake gn build system for some of their libraries (for example, webrtc, Angle, crashpad), but vcpkg has patches so that it just works with cmake.
They even have some extremely cursed libraries, such as LLVM, QT, and boost (cursed as in, these libraries is too big and impractical for vcpkg, vcpkg can easily waste gigs of space of caches and copies, "classic mode" can avoid some copies).
Then for linux, I believe you need an old version of glibc for portability, since it's backwards compatible but not forward compatible... (or you can use musl!)
Then for msys, I don't know why but the AI is telling me there is a static package for libraries, because I can only see QT-static on packages.msys2.org... But the DLL's are all dynamically linking to a bunch of other stuff so you can't use static libraries to avoid copying DLL's...
This is really bad for a library like freetype, since it links to like 40mb of pango/harfbuzz/icu crap (on vcpkg, it's like 500kb), and I think openAL had a similar thing.
And you could use vcpkg with msys, but it will download it's own copy of msys tools, so you could just use a standalone mingw/llvm-mingw binary if you set the PATH to the /bin folder and set the triplet to x64-mingw-dynamic

>>109277623
I use bitbake.

>>109282494
Setting rpath/runpath is easy and your build system should just handle it.

>>109277623
MinGW and makefiles, cmake or whatever is compatible with Linux.

>>109277623
Just set up my windows C++ environment myself.
The step by step process:
Install Msys2.
ucrt64 $ pacman -S --needed base-devel mingw-w64-ucrt-x86_64-toolchain
$ pacman -S --needed mingw-w64-ucrt-x86_64-cmake
urct64 $ pacman _S --needed mingw-w64-x86_64-ninja
Edit Environment Variables ->Path -> Add C:msysucrt64\bin to PATH.
Install git-*-64-bit.exe
VSCode -> Extentions: C/C++, CMake, CMake Tools
MyProject:
/scr/main.cpp
CMakeLists.txt
CMakePresets.json
> git submodule add https://github.com/microsoft/vcpkg.git
> .\vcpkg\vcpkg.exe new --application
> .\vcpkg\bootstrap-vcpkg.bat
> .\vcpkg\vcpkg.exe add port sdl3[vulcan], sdl3-image, sdl3-tff
Edit vcpkg.json
Edit .gitignore
Edit CMakeLists.txt
Edit CMakePresets.json
VSCode: Run Commands -> Cmake:Select preset
VSCode: Run Commands -> Cmake:Build

>>109285001
*C:msys64\ucrt64\bin to PATH*
Also I had some issues with vcpkg trying to select a visual studio target triplet and failing to build so I specified it in CMakePresets.json:

{
    "version": 3,
    "cmakeMinimumRequired": {
        "major": 3,
        "minor": 24,
        "patch": 0
    },
    "configurePresets": [
        {
            "name": "base",
            "hidden": true,
            "generator": "Ninja",
            "binaryDir": "${sourceDir}/build/${presetName}",
            "cacheVariables": {                
                "CMAKE_EXPORT_COMPILE_COMMANDS": true,
                "CMAKE_TOOLCHAIN_FILE": "${sourceDir}/vcpkg/scripts/buildsystems/vcpkg.cmake",
                "CMAKE_MAKE_PROGRAM": "C:/msys64/ucrt64/bin/ninja.exe",
                "VCPKG_TARGET_TRIPLET": "x64-mingw-static",
                "VCPKG_HOST_TRIPLET": "x64-mingw-static"
            }
        },
        {
            "name": "windows-ucrt-debug",
            "displayName": "Windows UCRT64 Debug (MinGW)",
            "inherits": "base",
            "condition": {
                "type": "equals",
                "lhs": "${hostSystemName}",
                "rhs": "Windows"
            },
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Debug",
                "CMAKE_C_COMPILER": "gcc",
                "CMAKE_CXX_COMPILER": "g++"
            }
        },
        {
            "name": "windows-ucrt-release",
            "displayName": "Windows UCRT64 Release (MinGW)",
            "inherits": "windows-ucrt-debug",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Release"
            }
        },

>>109285019
Address sanitizer is the only useful tool that holds C++ on equal memory safety as rust.
Without address sanitizer, you will get nothing when you read some bad memory, your debugger won't tell you anything happened, and it won't crash most of the time.
But asan does not exist on gcc mingw.
You can install llvm-mingw (it's just a github repo).
>static mingw vcpkg
sdl is pretty fat, I like DLL's for faster link times. since SDL would add a whole second since it's like ~10mb (Debug build).
Consider just adding a custom cmake command to copy the C++ mingw DLL's (libc++ / libunwind / opt. libpthread) to your build folder instead of always statically linking.
One reason to copy it, is because I already copy the address sanitizer DLL to my build folder + install, and it can't be statically linked (it's also inside the same directory as the mingw DLL's).
Setting mingw to your PATH is an option (I don't think anyone distributes asan builds), but setting everything to PATH makes it more likely that your code will not work on other PC's if you don't double-check if your binary has every DLL packaged (I use detect-it-easy, you can also use dependency walker).
But the only problem is that I use an absolute path to the DLL's... So that's annoying. It's already a cmake value that could be overridden, but it doesn't feel right.
At least you are not using clang-cl, because clang-cl has a asan DLL with the same name as the msvc asan DLL (it will not work), plus msvc's Asan lib/DLL is inside the PATH set by vsvarsall, and there is no "vsvarsall for clang-cl" so...linking + copying with the absolute path of Clang-CL is the only sane option (I say clang-cl but I just mean msvc flavored clang, I am not using clang-cl.exe wrapper).

File: 1784081695294.jpg (227 KB, 1485x875)

227 KB JPG

ide better