13

I just wrote my first makefile.

I'm a newbie and I'm still learning, so I was doing all the compiling in the command line. I have never written make files before so making it work made feel happy a lot.

like I just write `make` and boom it's compiled.

It's not much at all, in fact that was nothing, but it still made me feel like I'm getting better.

Comments
  • 4
    Great work! Wait until you find cmake 😄
  • 2
    @jschmold

    Jetbrains' CLion makes those, but I'm holding off until I get the hangs of make.

    with that said, I'm already facing a stupid problem with one rule getting skipped, I'll be hunting for a solution for a while.
  • 1
    @WildPotato

    The docs for CMake are absolutely stellar. I strongly recommend applying the concepts you learned to CMake, and using that. You’ll thank me later, but in case you’re skeptical, you’re not doing any “less” work than a makefile. You get more out of the box, with the ability to declare packages you need, separate modules, the whole nine yards, all with ease.

    It also has transferable concepts for Makefiles themselves, so it’s an all around win ☺️
  • 0
    @jschmold

    Oh I'm not skeptical, I know very well that a widely used tool isn't widely used for nothing, and I'll probably get to CMake sooner rather than later, in fact it's already installed.

    It's just that it's a little more intimidating and I've only been doing
    target: stuff
    stuff
    for now
  • 1
    @WildPotato
    I feel ya ☺️ Use git as your safety net. Every time something works, commit your code. That way you can wreck shit left right and center without any consequences. If I’d known I could use git as a paranoid cheat-the-system mechanic, I’d have learned a LOT faster than I did.

    Give it a shot? My discord is on my profile if you ever need pointers/help
  • 2
    @jschmold Oh I already know how to use git. TheOdinProject had a good lesson about it and provided some nice material.

    So far I haven't felt the need to check out (I assume that's the command to role back changes) but I haven't worked on any big projects really.

    I'm currently learning C++ because I realized that many project ideas I had are a lot harder to make with plain old C.

    PS. Accelerated C++ is great.
  • 2
    @WildPotato checkout is used to switch branches, revert is to go back
  • 6
    They're nice.
    Just glorified shell scripts, but you know.
    Nice.
  • 0
    I hate makefiles and usually go for build scripts instead.
  • 1
    Depends on what you want to achieve.

    Building software with dependencies?

    Please use a build system...
    Do not write one by yourself, especially if the code belongs to your company or you want to open source it.

    Just executing a linker / GCC program or a few commands without logic (if it fails, it fails....)… makefiles or short scripts are fine.

    Oh and congrats :)
  • 0
    @IntrusionCM
    Oh I'm still ways away from working in a company. This is even the first time I've heard the term "Build system"

    I'm familiar with building because that's what all IDEs do out of the box, and as it seems I have another thing to learn, and I doubt it's close to the last.
  • 1
    @WildPotato it depends on the programming language.

    A build system is mostly an abstraction to provide a uniform way of creating binaries -/ linked files.

    Eg
    - Check that compiler exist
    - Check which compiler version
    - Check for linker
    - Check linker flags
    - create and store these as variables
    - find necessary libraries
    - assure that during build each library dependency is fulfilled by adding eg necessary header files / libraries to compiler runtime variable
    - same for linking
    - done.

    There are tons of systems out there.

    Some generate Makefiles Like CMake , others have an own script -/ templating language and compiler.

    Sometimes it's called build automation software, but I find the term a bit misleading (CI)
  • 1
    Make is like C, simple but complicated at the same times, it's easy to make common mistakes, please read some best practices and exemple Makefiles.

    Mine aren't the best, but for reference I have a C and C++ one:
    https://github.com/awoimbee-42/...
    I also made some cool ones for python projects but not open source (made for a company)
  • 1
    Daaaamn son, that shit is like magic to me, good goin'!
  • 1
    Obligatory @FrodoSwaggins mention
  • 2
    @jschmold YUCK. I hate cmake. I have had to debug so many stupid cmake bugs. (Yes literally bugs in the application) I think the number of times it hasn’t worked for me is so far greater than the number of times it has.

    Another team at work gave up on cmake this week. They spent 1.75 years porting to it and realized it’s not happening.
  • 0
    @FrodoSwaggins
    Is there a better alternative you suggest?
  • 0
    @jschmold make... a few lines of bash... really any build system that actually works is a good alternative.
  • 0
    @FrodoSwaggins
    You make it sound like your opinions are stronger than your experience. 🤷‍♂️
  • 0
    @jschmold you’re wrong (shrug)
  • 0
    @jschmold depends.

    CMake is a Makefile generator.

    And the folks at KDE can tell ya a lot about the wonderful world of CMake bugs.

    Every build system has it's own caveats and fuckups. There is no perfect system.

    Even make has a lot of caveats, but thinking about how it works since 30 years plus makes me always realize how amazing it is....

    This kernel bug fix eg for dealing with make :
    https://git.kernel.org/pub/scm/...

    Exists because the make jobserver utilizes pipes for IPC. Why? because there wasn't an posix conform alternative 30 years ago.

    Still works.
  • 0
    @FrodoSwaggins
    “any build system that actually works”
    Sounds like a viewpoint built purely on bias, instead of on understanding cmake’s problems. @IntrusionCM proved what you were saying with the example from the KDE team, so I believe you now. I’ve just learned to be cautious accepting opinions when they’re heavily littered with disgust instead of logical points

    @IntrusionCM
    I’ve heard of other tools such as Bazel, Premake, Ninja, and Maven, but avoided them for various reasons. Usually hard to pick up, and my C++ interest is very hobbyist level. Do you have a personal preference?
  • 1
    @jschmold it depends.

    I guess it's the same with programming languages: find out what you like.

    While there's certainly more than enough people who hate the GNU build system (autohell)… it's battle proven.

    Unless you're building biiiig stuff that has complex dependencies, it's fine.

    It's mostly hated for M4 (scripting language) and because it's hard to keep a program/binary/library cross platform compatible over time. As such... Some configure.ac's look like clusterfuck, because they've aged - trying to be compatible with multiple OSes / libraries / compilers / libc's takes it's toll over time.

    Scons is written in Python. If you like Python, Scons should be in your list.

    CMake can be good, too - it usually starts to suck when you need to write extensions... What I dislike mostly about CMake is that or tries to solve many problems at once... Which means in reverse: A simple solution can have a clusterfuck of loopholes, as you really have to look behind the curtain of abstraction CMake spans for OS platform compatiblity.

    The newest kid on the block is meson...

    Meson is different, because it explicitly tries to solve problems on it's own. It's way less low level than the other build systems.

    Eg: the list of compilers is defined in meson itself, you can check for a c compiler, that's it.

    If the compiler is not defined in the meson source code, it will not be found.

    A LOT of arguments for or against is speed. In most cases it's relevant when you have a lot of dependencies... Otherwise. Nope.

    Take a bit of RAM, mount it as a temporary drive, and you've got with the massive core count nowadays enough horse power to build small to medium sized projects fast
  • 1
    As such, I can understand why most people use meson.

    There were already some big bugs, but most of it should be fixed by now.

    These are the most Common build systems for C/ C++ I know.
  • 2
    @jschmold I’ve been part of no less than ten teams that either were using cmake and tried to port over to it while I was there. It always went the same way.

    1. The decision to move over to it was never based on anything. It was like “I guess we should do this, cmake Is probably better than make right? It’s one “c” better. I wish I was exaggerating.

    2. Cmake for as much as it’s famous for “abstracting away the usual problems of a c++ project” seems to actually accentuate them instead. Because, cmake tries so hard to do something smart that if that smart thing isn’t what you want it’s all out war to try to convince it to do the actual correct thing. I saw this in 100% of applications.

    3. Cmake does not scale. Most of the bugs I hit were bugs when we tried to deploy it on high volume systems. Environment variable that I look at changed? Obviously frodoswaggins wants me to dump my build settings cache and set install root to /usr/bin!! Because of course. Every other story I have is insanity like this as well.

    Basically I maintained makefiles while my team struggled to iron out the bugs of their cmake system for a year because I had actual work to do. And what was the point if i did the work to maintain the “worse” system anyway? Our project when built takes up more than 100TB of virtual address space and the build generates hundreds of thousands of dynamic libraries and binaries. It’s huge, and it’s obvious that cmake has too many poor designs choices and bugs to build it. And every time the version changed it would break compatibility and they’d have to fix it all over again. I just have to look at that and ask myself who the fuck would want to put themselves through that!?
  • 2
    @IntrusionCM I totally agree with this statement. Cmake tried to solve too many problems and a lot of the facilities that they developed mutually conflict in very insane and obvious ways and writing cmake files that behave consistently is way harder than doing it in make.
  • 3
    @FrodoSwaggins
    Holy fuck 😳 Yeah I’m gonna learn from your experience and retract my suggestion to use CMake. That’s enough to scare me away from a technology. I’d rather have the responsibility myself than deal with that nonsense

    @WildPotato
    Maybe don’t learn CMake
  • 2
    @jschmold there have honestly been so many stories like this many of which were much worse but I actually can’t remember them because I’ve pushed it out of my memory. The thing I remembered is stay away.

    I’m not a gradle fan either. Granted I have only used it twice but it just gives me the same vibe as cmake I.e. over designed so I don’t have high hopes for it
  • 1
    @FrodoSwaggins
    So basically, just know your build tools enough to use Make or a script?
  • 3
    @jschmold here’s the thing. Make sucks too, but it does work. If you take the time to learn make, you can be very productive with it and you won’t waste time debugging stupid crap. It’s also a valuable skill because millions of projects use it. But it does take time to get good with it.

    Make is one of those tools where the first time you write a makefile it’s a few hundred lines. But over two decades of learning it you find that really 20 lines is all you need. But it takes time to get there and appreciate that those 20 lines do scale really well.

    Cmake was designed so that you don’t have to write those 20 lines. But you write 50-100 lines of cmake instead. So the question I always end up asking myself is... why?
  • 2
    @jschmold the thing is: know what you've written.

    I kind a hate it to write it down like this, but it's my personal opinion:

    In most open source projects, from which you could learn how to use a build system, you'll find not a build system.

    You'll find mostly a heavy traumatized and orphaned frankensteen. Build systems are usually the thing that's written once and only touched again if it absolutely must be touched.

    It's sad, but true.

    What @FrodoSwaggins says is: Choose the right tool for the right job.

    What he describes is basically the arch enemy of every lasagna abstraction layer: highly specialized, scalable, low level system.

    That just doesn't mix with most build systems, who are not low level or have high degrees of abstraction.

    Make is the right tool, because it's the closest low level, yet abstracted you'll get.

    Porting make to other low level solutions like Ninja is really hard. Like in let klingons heal you with pain sticks hard.

    What FrodoSwaggins does is not the common use case though.

    If I would choose analogies size wise:
    - Linux Kernel
    - Libreoffice
    - Chromium

    And these are "small" compared to what he described.
  • 2
    Make it is then.
Add Comment