Please – A cross-language build system • Hacker News Board

Re: Please – A cross-language build system

#81

Post by Ericson2314 » Sat, Nov 28, 2020, 7:47 PM UTC

tatskaari wrote: post #42

mdoms wrote: post #11

It's hard to tell what the value proposition is here, apart from vague hand-waving about parallelization. The quick start is not enough to get started actually building something. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

This makes me sad.

You hopefully have tried out many other build systems by now, been frusted with all of them, and only then made your own. And with all that experience with the status quo, marketing should be easy.

If you haven't done that, this project is a net-negative on the world, because the proliferation of build systems exacerbates Conway's law and balkanizes our software commons.

NIH in FOSS is not free.

Re: Please – A cross-language build system

#82

Post by haberman » Sat, Nov 28, 2020, 7:47 PM UTC

rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Makefiles operate at a low level of abstraction. The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments.

These tools operate at a higher level of abstraction. The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." The build system then turns that into a set of commands to run. This higher-level abstraction provides a bunch of compelling features:

- Reliability: it's easy to write Makefiles that are fragile, for example one that works when run on a single CPU but fails when run with -j, because of undeclared dependencies. When the tool is in charge, it has more control and can sandbox each build step so that undeclared dependencies simply won't be available in the sandbox.

- Reproducibility: similar to the previous point, it's easy to write a Makefile that produces incorrect results with an incremental rebuild. For example, unless you implement your own header scanning (or manually list your header dependencies) "make" won't know to rebuild a source file when a header changes. These tools can ensure that builds are reproducible and incremental rebuilds are always correct.

Besides that, working at a higher level generally means writing less code to accomplish the same task, and the code you do write is closer to expressing your actual intent compared with a Makefile.

Re: Please – A cross-language build system

#83

Post by japgolly » Sat, Nov 28, 2020, 7:47 PM UTC

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar

Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

Re: Please – A cross-language build system

#84

Post by rhencke » Sat, Nov 28, 2020, 7:48 PM UTC

Ericson2314 wrote: post #81

tatskaari wrote: post #42

Earlier quoted context omitted.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

This makes me sad. You hopefully have tried out many other build systems by now, been frusted with all of them, and only then made your own. And with all that experience with the status quo, marketing should be easy. If you haven't done that, this project is a net- negative on the world, because the proliferation of build systems exacerbates Conway's law and balkanizes our software commons. NIH in FOSS is not free.

Marketing can be hard not because you don't have something worth marketing, but because marketing is a skill-set largely orthogonal to software development.

Re: Please – A cross-language build system

#85

Post by ur-whale » Sat, Nov 28, 2020, 7:49 PM UTC

rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make is only good at one thing: calculating how to execute a dependency graph to produce a specific target.

Everything else that is needed for a modern build system is lacking:

    - expressive scripting language

    - platform-related configuration

    - feature-related configuration

    - handling hierarchical projects

    - properly handling rebuilds when the Makefile itself has been changed

    - dealing with dynamically generated parts of the dependency graph

    - handling third-party dependencies

    - build reproducibility

    - etc... the list is very long

This is why people these days mostly take the path of generating Makefiles, because make is only good at one thing: executing a statically defined dependency graph.

Re: Please – A cross-language build system

#86

Post by klodolph » Sat, Nov 28, 2020, 7:49 PM UTC

rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make has a laundry list of problems:

- Cannot handle multiple outputs for a single rule

- Does not rebuild when flags change

- Make rules may contain implicit dependencies

- Slow for large codebases

- Does not understand how to build for multiple platforms, sucks for cross-compiling

- Recursive make sucks (job control does not work across recursive invocation boundaries)

- You must create output directories yourself

- You must create your own rule to clean

This adds up to a fragile & slow build system, where you have to do a full rebuild to have a reasonable level of assurance that your build is correct—incremental builds aren’t safe.

There have been a few attempts to make a “better make” over the years like Jam, SCons, Ninja, Tup, etc. each with their own pros and cons.

The new generation of build tools—Bazel, Buck, Pants, and Please are all an attempt to redesign build systems so that the design is resistant to the flaws that plague Make build systems. You can use a shared cache (shared between different users) fairly easily, and you have reasonable assurance than incremental builds are identical to full builds (so your CI pipeline can move a lot faster, developers almost never have to "make clean" when they change things, etc).

Personally I’m working on a project right now that uses Bazel (which is similar to Please) and is for an embedded system. It’s been a great experience, and I can pass a flag to Bazel to tell it to build for the embedded target using the cross compiler or for the native host--that makes it easy to share code between tools and the target system, and I can do things like write tests that run on both the target & host. Anyone who does any cross-compiling is missing out if they are using Make—but, do note that setting up a cross-compiling toolchain in Bazel isn’t exactly a cakewalk.

Re: Please – A cross-language build system

#87

Post by dfgdghdf » Sat, Nov 28, 2020, 7:50 PM UTC

japgolly wrote: post #83

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

Some people really dislike the JVM, and Please is written in Go.

Re: Please – A cross-language build system

#88

Post by grosales » Sat, Nov 28, 2020, 7:51 PM UTC

japgolly wrote: post #83

> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?

I also was trying to figure out why I would use this over Bazel. Then I remember reading a story yesterday about how ex-googlers miss their tooling when they leave. Their CTO is an ex-googler, so maybe this is the reason.

Re: Please – A cross-language build system

#89

Post by junon » Sat, Nov 28, 2020, 7:52 PM UTC

throwawaylabor wrote: post #69

rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make build configurations can be difficult to understand for newcomers in the industry. If the goal is to obscure the code, by all means continue using the older tools. If the goal is continued maintenance, then encouraging new engineers to explore and read the codebase with tools they can comprehend is critical. disclaimer: have not used these particular tools, but the domain is nice and polite

I have use all of these tools and your take isn't accurate at all. Make doesn't obfuscate anything more than Plz or CMake or whatever.

Here are some real reasons why Make isn't the end-all:

- Make doesn't allow platform selection in a nice way. - Make doesn't work on Windows natively (no, NMake doesn't count). - Recursive make doesn't work well at all. - Make doesn't track byproducts or deleted artifacts. - Make doesn't have auto-clean. - Make doesn't facilitate out-of-source builds. - Make itself isn't a scripting language (arguably good/bad). - Make doesn't facilitate compiler selection cross-platform, so things like MSVC are nearly impossible to integrate nicely without the use of the developer tools prompt. - Make can't (elegantly) handle a number of rule cases, such as single-input multiple-output rules (it can, but it's a hack).

Not sure why you think Make is unapproachable. That's like saying shell scripting is unapproachable. No developer worth a damn is going to avoid shell scripting, and as long as they understand "this file turns into this file using this command" then Make makes sense.

As with all tools, Make and Autotools and CMake and probably Plz will be misused by developers that think they're being clever. In actuality, they make things worse at best and unusable/unmaintainable at worst.

As a build systems designer, I've evaluated Plz personally and found it to be neat but not suitable for most of the problems I think build systems should solve.

Re: Please – A cross-language build system

#90

Post by dfgdghdf » Sat, Nov 28, 2020, 7:52 PM UTC

rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

The short answer is yes, they are (well, can be) easier and faster and work better.

I would strongly recommend watching this talk if you want to understand why systems like Bazel and Please were created:

Build Systems with Andrey Mokhov (Jane Street)

https://www.youtube.com/watch?v=V9YA32uV3Ls