Other Building with bmake

Is bmake stupid or something?

  • Yes, very stupid.

    Votes: 0 0.0%
  • No, you are stupid.

    Votes: 2 50.0%
  • 50/50

    Votes: 2 50.0%

  • Total voters
    4
So i tried building a library with bmake. First it wants to build 2 extra object files per source file. OK, cool, whatever. When it reaches a cpp file it barks about not knowing how to build the extra objects though... OK. I disable it and now it's building but then i notice it's using CFLAGS for building cpp files even while it seems to notice what they are (calls c++ to compile them) so i need to know for technical reasons...
 
It has less "gizmos" than gmake.

Also, if you have an obj folder, it will implicitly cd into it before running the Makefile script which I personally find bizarre because it breaks all the paths.

CMake can seem to wrangle it so I must be doing something wrong. Therefore I abstain from the vote!
 
CMake can seem to wrangle it so I must be doing something wrong. Therefore I abstain from the vote!

Now CMake is whole different can of worms.

2020-02-cmake.png
 
Code:
all:
    pwd
    mkdir -p obj

Run this twice and you will get a different output the second time with bmake.

True madness!

Perhaps ekvz we need a 4th poll option "No, I are stupid." ;)
 
bmake does not do anything you didn't tell it to via Makefiles or .mk stuff, so sorry, but my vote goes .... :cool:

But the mk stuff is what came with bmake and i did nothing but set SRCS to a list of source files, LIB to 'foo' and included bsd.lib.mk! Whatever, bmake is leading for now i guess. For now... ;)
 
Write your own build glue then, doing what you want. You don't call dog stupid just because it was trained to bark on trespassers ;)
 
Write your own build glue then, doing what you want. You don't call dog stupid just because it was trained to bark on trespassers ;)

You have a point there. This was my first idea anyways but then i thought: "No, you go read the documentation. You will use this as it's supposed to be used." Guess, it' plan A again then. Explicitly defining a rule for something as simple as a cpp file (which i guess i'll have to do to stop it from using CFLAGS) feels pretty weird though.
 
Note that base system uses CFLAGS when building C++ code too, check e.g. /usr/src/lib/atf/libatf-c++/Makefile.

That's interesting and strange at the same time. What if i'd really need to define different flags for C++ (the use of CFLAGS isn't build breaking in my case but it's producing a warning and my OCD is very much triggered by it...)?

By the way i am actually using the standalone distribution of bmake right now (for it's supposed cross platform abilities) but i guess it's not surprising that FreeBSDs mk files are somewhat similar.
 
So, bmake is a BSD make, just the version from NetBSD, right?
In what fashion is it better than the native FreeBSD make?

I can take two approaches to your question here.
  • You are using bmake, it should work, why doesn't it. In that case, we should help you debug what you're doing wrong, or debug what is wrong with bmake.
  • There is no advantage to using bmake. It might be broken, you might be using it wrong. Stop doing it, there is no point wasting time on improving the situation.
I can see a very good logical reasons to use the native make (I actually nearly always do that when developing on FreeBSD, even for projects that are portable to other OSes, by having multiple makefiles). Because: when in Rome, do as the romans. I can also see a few reasons to using gmake: Compatibility with projects that also have to be build on other OSes (in particular Linux), and you want to write a single make file that works on all platforms (good luck with that though, you end up with if statements buried somewhere anyway). Also gmake has a few neat features that make life easier (or more confusing, that's a question of taste). I can see a reason to use parallel makes on compute clusters, where you can use the power of dozens or hundreds of machines to speed up building massively. I can see a really good reason to use a good, modern build system (such as Bazel), simply because once you learn it, life is so much more pleasant and efficient than with the horribly old-fashioned and bizarre make file. But I haven't seen a good reason to use bmake. If you have one, please tell me, because if it has particular strengths, I might start using it too.
 
So, bmake is a BSD make, just the version from NetBSD, right?

No, at least not exactly. bmake is supposedly a portable version based on NetBSD's make.

In what fashion is it better than the native FreeBSD make?

It is available elsewhere.

I can see a very good logical reasons to use the native make (I actually nearly always do that when developing on FreeBSD, even for projects that are portable to other OSes, by having multiple makefiles). Because: when in Rome, do as the romans. I can also see a few reasons to using gmake: Compatibility with projects that also have to be build on other OSes (in particular Linux), and you want to write a single make file that works on all platforms (good luck with that though, you end up with if statements buried somewhere anyway). Also gmake has a few neat features that make life easier (or more confusing, that's a question of taste). I can see a reason to use parallel makes on compute clusters, where you can use the power of dozens or hundreds of machines to speed up building massively.

I don't have any kind of huge requirements so stuffing it all into a single file should very well be possible. Sure there might be some switches (it's so simple this time i think i could even get away without those). As for maintaining multiple build scripts: I guess it's a matter of taste but it's not for me unless i absolutely have to (which i doubt as i am not going to support anything weird like VC - if someone wants this they can write their own build scripts). As for using bmake to do that, well, it's not exactly a requirement. It would have been a nice touch but gmake more or less has the same property (being widely available). It's just not as ideologically fitting but oh well. If that fails plain shell scripts should be more than sufficient for a simple use case.

I can see a really good reason to use a good, modern build system (such as Bazel), simply because once you learn it, life is so much more pleasant and efficient than with the horribly old-fashioned and bizarre make file.

Thanks, i'll check this out. My relation to modern build systems is a little, let's say, fragile. After years of running into various types of build systems i've come to the conclusion that they all pretty much suck. Often worse than any kind of (plain) make. Maybe this one is the exception.

But I haven't seen a good reason to use bmake. If you have one, please tell me, because if it has particular strengths, I might start using it too.

It's available elsewhere and seems reasonably similar to FreeBSD's version of make. The rationale behind using it was being able to do cross platform builds with bmake while getting away with the system version of make on FreeBSD.

Edit: I've looked into Bazel and... Good lord, i am speechless. Don't get me wrong if someone feels that's the right fit for their project more power to them but how something like that would be useful for my tiny C project (or really any of my projects regardless of language or size) is absolutely beyond me. Seeing how this thing is written in Java (aka requires a whole VM just to build something) and has documentation that thinks of external dependencies either as other Bazel projects or something you pull from Maven i'd rather chose cmake and i don't like cmake the slightest. Well, in any case something like that has zero chance of convincing me to abandon those old-fashioned bizarre makefiles. There is simply no gain for me. Just a lot of downsides.
 
It's available elsewhere and seems reasonably similar to FreeBSD's version of make. The rationale behind using it was being able to do cross platform builds with bmake while getting away with the system version of make on FreeBSD.
That actually sounds pretty good. When I first ran into cross-platform make problems, my solution was sort of similar: just install gnu make everywhere. Which sounds easy, but it turns out that gnu make is not always easy to install, and there are places where GPL'ed software is very unwelcome or very hard to install (proprietary OSes). I like your solution of using a relatively simple make (the BSD make, here in the bmake version), which can probably be compiled and installed pretty much everywhere.

What I do today, for the few personal projects that actually need interestingly complex make files: I write most of the bulk of the makefile in a very simple fashion, specifying mostly dependencies and what source goes into what executable. Then I have two main make files, called GNUmakefile and BSDmakefile,
which set up make-dependent syntax and rules, and determine which OS is running (the syntax for if statements and include is highly make-dialect dependent). They then include OS-dependent make files (such as Makefile.FreeBSD and Makefile.Darwin and Makefile.FreeBSD.11.3) which do nothing by set variables that depend on the OS (like /usr/local versus /usr versus /opt), and in one case I also have Makefile.<hostname> for software that depends on which computer it is on. Finally, all of them include the bulk file I described first. You end up with a dozen files, but each file is very simple and clean, and many of them are very short. And the one that is very long (the dependency / rule file) is super simple. I'm not sure I would recommend this technique to others though, you need to be pretty OCD to do maintenance on it.

For small projects, I typically don't bother with make at all. Modern computers are so fast, I have a tiny "install" script, which simple deleted all object files and executables, and starts from scratch, with the compile/link/install commands typed right in there. If it crashes, you fix the source code until it starts working. And since the compiles are so far, the inefficiency of recompiling things needlessly doesn't matter.

Edit: I've looked into Bazel and... Good lord, i am speechless. Don't get me wrong if someone feels that's the right fit for their project more power to them ...
Yes, installing Bazel is not for the faint of heart. It also requires being pretty good in Python, since the make files use Python syntax and semantics. I think it makes a great tool for very large projects. For something that's 10 files and 1000 lines ... there is a german saying about "shooting at sparrows with cannons" (small bird, large gun). I'm also not sure how well Bazel interacts with outside software that is versioned in itself instead of using the "monorepo" development philosophy.

As you can see, there are many ways to skin the cat.
 
What I do today, for the few personal projects that actually need interestingly complex make files: I write most of the bulk of the makefile in a very simple fashion, specifying mostly dependencies and what source goes into what executable. Then I have two main make files, called GNUmakefile and BSDmakefile,
which set up make-dependent syntax and rules, and determine which OS is running (the syntax for if statements and include is highly make-dialect dependent). They then include OS-dependent make files (such as Makefile.FreeBSD and Makefile.Darwin and Makefile.FreeBSD.11.3) which do nothing by set variables that depend on the OS (like /usr/local versus /usr versus /opt), and in one case I also have Makefile.<hostname> for software that depends on which computer it is on. Finally, all of them include the bulk file I described first. You end up with a dozen files, but each file is very simple and clean, and many of them are very short. And the one that is very long (the dependency / rule file) is super simple. I'm not sure I would recommend this technique to others though, you need to be pretty OCD to do maintenance on it.

I see. So it's basically pretty much really just (if one ignores the BSD/GNU split) a one script approach but broken down into multiple smaller parts for better organization. While i probably won't do that for a small project i can very much see the appeal of going about it this way. I like having things neatly organized at least as much as i dislike duplication.

For small projects, I typically don't bother with make at all. Modern computers are so fast, I have a tiny "install" script, which simple deleted all object files and executables, and starts from scratch, with the compile/link/install commands typed right in there. If it crashes, you fix the source code until it starts working. And since the compiles are so far, the inefficiency of recompiling things needlessly doesn't matter.

Agreed. Now that even Windows features a unix-like environment without having to resort to cygwin or random win32 ports of userland utilities this has also become more practical than ever before. I have no personal experience with how easy or hard it is to actually use this on Windows but i feel being able to point at the functionality being officially supported is a sufficient answer to any questions as to what to do with this strange *.sh file.
 
OK, i think i have it figured out at least partly and i fear i'll have to vote 50/50 as even when i correct my own stupidity (of expecting Debian to ship anything semi usable which they don't - the package in buster comes with a set a set of mk files that might not even belong to bmake but rather NetBSD itself and even if they do they are almost 10 years old...) it still thinks it's appropriate to use CFLAGS for building C++ but otherwise the build works out of the box now.

I'll probably use kpedersen's instructions anyways though. I am not 100% sure yet as i would have really liked to use as much existing logic as possible but i guess it's simply safer while also giving control over CXXFLAGS on top of that.
 
Back
Top