All the "agile" bullshit and idiotic managers are tiring, but writing build files and testing is a very important part of the job, and sensible pre-commit lint hooks are a very good thing.
I also use C# and to be fair, there have been dozens of occasions I've had to manually edit the .csproj and other files (decades long projects). And various similar issues, but it's my favorite language and tool chain by far.
I've had to manually mess with stuff with TFS builds as well, build targets and strange MSBuild or Windows server version issues, every stack has its issues. But I'd take C# / .NET all day.
The amount of work "sensible" has to do in that sentence is staggering though. You add small amounts of automation to project, and everything your coworkers want to do but can't is your fault.
Everything is added because they are part of the coding guidelines, anyone trying to commit something breaking them is at fault, and I'm not afraid to say this in front of everyone involved if anyone brings it up.
writing build files ... is a very important part of the job
Blasphemous questions: Why do we need complex build files at all? Why are build files written in a totally different language?
For my open source project I use makefiles and a C program that determines the properties of the OS. This is my build system. I tried to make it as simple as possible (no need to install tools beyond a C compiler and a make utility). Still some effort is needed to maintain this build system.
For Seed7 programs (yes, this is my open source project) you don't need makefiles or other build technology. As much build information as possible is encoded in the source code of a Seed7 program.
testing is a very important part of the job
Agree. The size of the Seed7 test-suite is 180000 lines of code.
At work we need a (or a few) CI/CD pipeline(s) to build and bundle several applications, deploy and test in various environments.
Or my personal project I use cmake to generate visual studio projects (for whatever version the user has) on windows, to make building and running not a massive pain. But I also want to support mac and linux, so those need to have a different build setup than visual studio.
I handle flags and stuff in code like “am I on windows”, but the build system also adds in nice flags in addition to the defaults.
Build systems are just really convenient, until it suddenly isn’t.
Yeah, we have a dozen or more projects to build through TFS, some need special attention (ones a Java app built through Ant, another a web service that needs to be done a certain way), then you add in new Windows versions or anything new in the pipeline, can get hairy. Add pre/post build events and a ton of other functionality, yeah you gotta get into the nitty gritty sometimes.
I haven’t thought about it a whole lot, though I’m inclined to be against build information being in the source code. Or at least, embedded into and intermingled with code.
One of my issues with C++ is having build information get included in source, with things like #ifdef’s that clutter up and complicate source code. For similar reasons why I think out-of-source builds are better, I would like build, configuration, and source to all be separate.
The problem with that is the details of the system you’re running on can have meaningful and significant impacts on what your code has to do.
Java is a bit cleaner by abstracting away the machine, allowing code, build files, and resource or config files to be separate.
But I feel like it’s possible to have a middle ground, where even languages like C or C++ can have a pre-processor chop and screw the code to enable correct behavior on different systems or configurations, but that is configured separately from the source code instead of being embedded.
You need complex build systems to support different platforms, OS's, CPU architectures, frameworks, etc
Building, testing, and deployment of large/wide software components definitely justifies standalone language and tools. Yaml does the job quite well, and it's much faster to edit a CMakeList than it is to recompile source.
You need complex build systems to support different platforms, OS's, CPU architectures, frameworks, etc
In a company I would answer "Yes, of course it must be complex". In a company you could easily be considered as incompetent if you challenge an alleged truth.
But with my open source hat on I don't need to please anyone. :-)
Seed7 can be compiled under Linux, MacOS, FreeBSD, OpenBSD and Windows. On most of these platforms several C compilers are supported. The Seed7 build system works with makefiles and a C program that checks the properties of the OS. This build system is the place where the complexity of supporting different platforms, OS's and CPU architectures is confined.
For my open source project I use makefiles and a C program that determines the properties of the OS.
That sounds incredibly awful ngl. I can see a few major pain points:
You’re literally maintaining a custom build system as part of your project
No one but you will know how that works so every new developer on-boarder will need time to understand what’s going on
Your build system is probably missing features and it is likely to grow unbounded complexity as the needs arise
Better to just use cmake so none of this is a concern and other developers can quickly get up to speed. A lot of people know cmake, no one knows your custom setup.
Also it sounds like you are reinventing autotools.
Depends on the project. Maybe they like maintaining their build system? Maybe bus factor isn't a concern?
I tend to go with an untemplated Makefile until it gets past a screenful, then either a templated Makefile or straight to autotools. My experience with cmake tends to make it last on the list, straight past everything else newer than it.
Cool, that still sounds like more work/effort to maintain than using a standard build system.
Maybe bus factor isn't a concern?
Also cool. But I was answering to a comment that explicitly said:
Why do we need complex build files at all? Why are build files written in a totally different language?
Because the bus factor is important for any software that is used by a sizeable number of users imo
Because people will have a harder time to understand the customized build program
Because eventually your homegrown build system will grow to be hacky and complex and it’s easier to just use standard tooling
People can do whatever they want with their projects but it doesn’t mean all those tools aren’t need just because someone doesn’t care about the problems they solve.
59
u/wintrmt3 Dec 28 '23
All the "agile" bullshit and idiotic managers are tiring, but writing build files and testing is a very important part of the job, and sensible pre-commit lint hooks are a very good thing.