1. 5
  1.  

  2. 8

    For reference, GNU Make inherited pattern rules from Plan9’s mk(1), which was a (much nicer, syntactically), rebuild of Make from the ground up by the original author.

    1. 4

      This is an interesting thread on making Makefiles which are POSIX-compatible. The interesting thing is that it’s very hard or impossible, at least if you want to keep some standard features like out-of-tree builds. I’ve never restricted myself to write portable Makefiles (I use GNU extensions freely), but I previously assumed it wasn’t that bad.

      That this is so hard is maybe a good example of why portability to different dependencies is a bad goal when your dependencies are already open source and portable. As many posters in the thread say, you can just use gmake on FreeBSD. The same goes for many other open source dependencies: If the software is open source, portability to alternatives to that software is not really important.

      1. 4

        you can just use gmake on FreeBSD.

        I can, but I don’t want to.

        If you want to require any specific tool or dependecy, fine, that’s your prerogative, just don’t force your idea of the tool’s cost on me. Own your decision, if it impacts me, be frank about it, just don’t bullshit me that it doesn’t impact me just because the cost for you is less than the cost for me.

        The question of why don’t you use X instead of Y is nobody’s business but mine. I fully understand and expect that you might not care about Y, please respect my right not to care about X.

        1. 11

          That’s very standard rhetoric about portability, but the linked thread shows it’s not so simple in this case: It’s essentially impossible to write good, portable Makefiles.

          1. 5

            Especially considering how low cost using GNU Make is, over i.e. switching OS/architecture.

            1. 2

              It’s just as easy to run BSD make on Linux as it is to run GNU make on BSDs, yet if I ship my software to Linux users with a BSD makefile and tell them to install BSD make, there will hardly be a person who wouldn’t scorn at the idea.

              Yet Linux users expect BSD users not to complain when they do exact same thing.

              Why is this so hard to understand, the objection is not that you have to run some software dependency, the objection is people telling you that you shouldn’t care about the nature of the dependency because their cost for that dependency is different than yours.

              I don’t think that your software is bad because it uses GNU make, and I don’t think that using GNU make makes you a bad person, but if you try to convince me that “using GNU make is not a big deal”, then I don’t want to ever work with you.

              1. 2

                Are BSD makefiles incompatible with GNU make? I actually don’t know.

                1. 2

                  The features, syntax, and semantics of GNU and BSD make are disjoint. Their intersection is POSIX make, which has almost no features.

                  …but that’s not the point at all.

                  1. 2

                    If they use BSD specific extensions then yes

              2. 2

                Posix should really standardize some of GNU make’s features (e.g. pattern rules) and/or the BSDs should just adopt them.

                1. 5

                  I get the vibe at this point that BSD intentionally refuses to make improvements to their software specifically because those improvements came from GNU, and they really hate GNU.

                  Maybe there’s another reason, but why else would you put up with a program that is missing such a critically important feature and force your users to go thru the absurd workarounds described in the article when it would be so much easier and better for everyone to just make your make better?

                  1. 4

                    I get the vibe at this point that BSD intentionally refuses to make improvements to their software specifically because those improvements came from GNU, and they really hate GNU.

                    Really? I’ve observed the opposite. For example, glibc refused to adopt the strl* functions from OpenBSD’s libc, in spite of the fact that they were useful and widely implemented, and the refusal to merge them explicitly called them ‘inefficient BSD crap’ in spite of the fact that they were no less efficient than existing strn* functions. Glibc implemented the POSIX _l-suffixed versions but not the full set from Darwin libc.

                    In contrast, you’ll find a lot of ‘added for GNU compatibility’ functions in FreeBSD libc, the *BSD utilities have ‘for GNU compatibility’ in a lot of places. Picking a utility at random, FreeBSD’s du [has two flags that are listed in the man page as first appearing in the GNU version], whereas GNU du does not list any as coming from BSDs (though -d, at least, was originally in FreeBSD’s du - the lack of it in GNU and OpenBSD du used to annoy me a lot since most of my du invocations used -d0 or -d1).

                    1. 2

                      The two are in no way mutually exclusive.

                    2. 1

                      Maybe there’s another reason, but why else would you put up with a program that is missing such a critically important feature and force your users to go thru the absurd workarounds described in the article when it would be so much easier and better for everyone to just make your make better?

                      Every active software project has an infinite set of possible features or bug fixes; some of them will remain unimplemented for decades. glibc’s daemon function, for example, has been broken under Linux since it was implemented. The BSD Make maintainers just have a different view of the importance of this feature. There’s no reason to attribute negative intent.

                      1. 1

                        The BSD Make maintainers just have a different view of the importance of this feature

                        I mean, I used to think that too but after reading the article and learning the details I have a really hard time continuing to believe that. we’re talking about pretty basic everyday functionality here.

                      2. 1

                        Every BSD is different, but most BSDs are minimalist-leaning. They don’t want to add features not because GNU has them, but because they only want to add things they’ve really decided they need. It’s an anti-bloat philosophy.

                        GNU on the other hand is basically founded in the mantra “if it’s useful then add it”

                        1. 6

                          I really don’t understand the appeal of the kind of philosophy that results in the kind of nonsense the linked article recommends. Why do people put up with it? What good is “anti-bloat philosophy” if it treats “putting build files in directories” as some kind of super advanced edge case?

                          Of course when dealing with people who claim to be “minimalist” it’s always completely arbitrary where they draw the line, but this is a fairly clear-cut instance of people having lost sight of the fact that the point of software is to be useful.

                          1. 4

                            The article under discussion isn’t the result of a minimalist philosophy, it’s the result of a lack of standardisation. BSD make grew a lot of features that were not part of POSIX. GNU make also grew a similar set of features, at around the same time, with different syntax. FreeBSD and NetBSD, for example, both use bmake, which is sufficiently powerful to build the entire FreeBSD base system.

                            The Open Group never made an effort to standardise any of them and so you have two completely different syntaxes. The unfortunate thing is that both GNU Make and bmake accept all of their extensions in a file called Makefile, in addition to looking for files called GNUmakefile / BSDmakefile in preference to Makefile, which leads people to believe that they’re writing a portable Makefile and complain when another Make implementation doesn’t accept it.

                  2. 7

                    But as a programmer, I have to use some build system. If I chose Meson, that’d be no problem; you’d just have to install Meson to build my software. Ditto if I chose cmake. Or mk. Why is GNU make any different here? If you’re gonna wanna compile my software, you better be prepared to get my dependencies onto your machine, and GNU make is probably gonna be one of the easiest build systems for a BSD user to install.

                    As a Linux user, if your build instructions told me to install bsdmake or meson or any other build system, I wouldn’t bat an eye, as long as that build system is easy to install from my distro’s repos.

                    1. 3

                      Good grief, why is this so difficult to get through? If you want to use GNU make, or Meson, or whatever, then do that! I use GNU make too! I also use Plan 9’s mk, which few people have installed, and even fewer would want to install. That’s not the point.

                      The problem here has nothing to do with intrinsic software properties at all, I don’t know why this is impossible for Linux people to understand.

                      If you say “I am using GNU make, and if you don’t like it, tough luck”, that’s perfectly fine.

                      If you say “I am using GNU make, which can’t cause any problem for you because you can just install it” then you are being ignorant of other people’s needs, requirements, or choices, or you are being arrogant for pretending other people’s needs, requirements, or choices are invalid, and of course in both cases you are being patronizing towards users you do not understand.

                      This has nothing to do with GNU vs. BSD make. It has nothing to do with software, even. It’s a social problem.

                      if your build instructions told me to install bsdmake or meson or any other build system, I wouldn’t bat an eye, as long as that build system is easy to install from my distro’s repos.

                      And this is why Linux users do not understand the actual problem. They can’t fathom that there are people for whom the above way of doing things is unacceptable. It perfectly fine not to cater to such people, what’s not fine is to demand that their reasoning is invalid. There are people to whom extrinsic properties of software are far more important than their intrinsic properties. It’s ironic that Linux people have trouble understanding this, given this is the raison d’etre for the GNU project itself.

                      1. 5

                        I think the question is “why is assuming gmake is no big deal any different than assuming meson is no big deal?” And I think your answer is “those aren’t different, and you can’t assume meson is no big deal” but you haven’t come out and said that yet.

                    2. 1

                      I can, but I don’t want to.

                      Same. Rewriting my Makefiles is so annoying, that so far I have resigned to just calling gmake on FreeBSD. Maybe one day I will finally do it. I never really understood how heavily GNUism “infected” my style of writing software, until I switched to the land of the BSD.

                    3. 2

                      What seems to irk BSD users the most is putting gnuisms in a file called Makefile; they see the file and expect to be able to run make, yet that will fail. Naming the file GNUMakefile is an oft-accepted compromise.

                      I admit I do not follow that rule myself, but if I ever thought a BSD user would want to use my code, I probably would follow it, or use a Makefile-generator.

                      1. 4

                        I’d have a lot more sympathy for this position if BSD make was actually good, but their refusal to implement pattern rules makes it real hard to take seriously.

                        1. 2

                          I’d have a lot more sympathy for this position if BSD make was actually good

                          bmake is able to build and install the complete FreeBSD source tree, including both kernel and userland. The FreeBSD build is the most complex make-based build that I’ve seen and is well past the level of complexity where I think it makes sense to have hand-written Makefiles.

                          For the use case in mind, it’s worth noting that you don’t need pattern rules, bmake puts things in obj or $OBJDIRPREFIX by default.

                      2. 1

                        That this is so hard is maybe a good example of why portability to different dependencies is a bad goal when your dependencies are already open source and portable.

                        I mean, technically you are right, but in my opinion, you are wrong because of the goal of open source.

                        The goal of open source is to have as many people as possible using your software. That is my premise, and if it is wrong, the rest of my post does not apply.

                        But if that is the goal, then portability to different dependencies is one of the most important goals! The reason is because it is showing the user empathy. Making things as easy as possible for users is being empathetic towards them, and while they may not notice that you did it, subconsciously, they do. They don’t give up as easily, and in fact, sometimes they even put extra effort in.

                        I saw this when porting my bc to POSIX make. I wrote a configure script that uses nothing other than POSIX sh. It was hard, mind you, I’m not denying that.

                        But the result was that my bc was so portable that people started using on the BSD’s without my knowledge, and one of those users decided to spend effort to demonstrate that my bc could make serious performance gains and help me to realize them once I made the decision to pursue that. He also convinced FreeBSD to make my bc the system default for FreeBSD 13.

                        Having empathy for users, in the form of portability, makes some of them want to give back to you. It’s well worth it, in my opinion. In fact, I just spent two days papering over the differences between filesystems on Windows and on sane platforms so that my next project could be portable enough to run on Windows.

                        (Oh, and my bc was so portable that porting it to Windows was little effort, and I had a user there help me improve it too.)

                        1. 5

                          The goal of open source is to have as many people as possible using your software.

                          I have never heard that goal before. In fact, given current market conditions, open source may not be the fastest way if that is your goal. Millions in VC to blow on marketing does wonders for user aquisition

                          1. 1

                            That is true, but I’d also prefer to keep my soul.

                            That’s the difference. One is done by getting users organically, in a way that adds value. The other is a way to extract value. Personally, I don’t see Open Source as having an “extract value” mindset in general. Some people who write FOSS do, but I don’t think FOSS authors do in general.

                          2. 4

                            The goal of open source is to have as many people as possible using your software.

                            I actually agree with @singpolyma that this isn’t necessarily a goal. When I write software and then open source it, it’s often stuff I really don’t want many people to use: experiments, small tools or toys, etc. I mainly open source it because the cost to me of doing it is negligible, and I’ve gotten enough neat random bits and pieces of fun or interesting stuff out of other people’s weird software that I want to give back to the world.

                            On the other hand, I’ve worked on two open source projects whose goal was to be “production-quality” solutions to certain problems, and knew they weren’t going to be used much if they weren’t open source. So, you’re not wrong, but I’d turn the statement around: open source is a good tool if you want as many people as possible using your software.