
Please – A Cross-Language Build System - nikolay
https://please.build
======
qznc
I'd say meson is the most direct competitor. They don't mention it in the FAQ
though.

[http://mesonbuild.com/](http://mesonbuild.com/)

~~~
lolikoisuru
>supported languages include C, C++, D, Fortran, Java, Rust

So it isn't general purpose?

------
CJefferson
Cross language but not cross platform -- no windows support, and none planned.

~~~
qznc
Noted. [https://github.com/qznc/annoying-build-
systems#please](https://github.com/qznc/annoying-build-systems#please)

~~~
arunc
No love for D's DUB on your list?

~~~
qznc
I left out package managers from all languages and focused on generic build
systems. The line is blurry though. Feel free to send a pull request.

------
bringtheaction
I Googled to find the repository of a build system I wanted to mention and
stumbled upon something else that I found interesting;
[https://shakebuild.com/](https://shakebuild.com/)

> Shake is a library for writing build systems. Most large projects have a
> custom-written build system, and developers working on the project are
> likely to run the build system many times a day, spending a noticeable
> amount of time waiting for the build system. This document explains why you
> might pick Shake over alternative tools for writing build systems (e.g.
> make, Ant, Scons).

[https://shakebuild.com/why](https://shakebuild.com/why)

Shake is written in Haskell and is open source.

~~~
carterschonwald
One of the larger public projects working to migrate to shake over time is
ghc. The current ghc build system uses a recursive make setup, and all that
such entails. (:

------
ComputerGuru
Since this thread has long since devolved into a discussion about build
systems in general: if you don’t need a build system with Windows support, go
with tup which is otherwise awesome. If you don’t care about bloat in your dev
tools, go with meson (modern scons replacement). If you need cross platform
and don’t like requirements on needless runtimes, I’m still searching for a
good replacement for cmake (BSD Makefiles accomplish much of the same with a
saner syntax just not as portably unless you need the ninja/msvc/qt/xcode
intermediate build files).

Premake was promising but I fear it fell victim to early hype syndrome.

~~~
aidenn0
What's wrong with tup on windows? (I've never used it on windows, but its docs
say that windows is supported).

~~~
ComputerGuru
Tup requires fuse because they use fuse to monitor the file system for changes
instead of kqueue/inotify/FindFirstChangeNotification.

Fuse support on Windows is a no-go, very unstable, broken, and unavailable by
default.

------
jopsen
Why do all these build systems have magic built-in rules and special syntax?
Custom languages, etc.

makefiles without any magic are comprehensible, but people quickly add magic
:(

~~~
aidenn0
gnumake has at least a half-dozen magic built-in rules, no?

~~~
lloeki
A bit more than a half dozen, but mostly inconsequential:

[https://www.gnu.org/software/make/manual/html_node/Catalogue...](https://www.gnu.org/software/make/manual/html_node/Catalogue-
of-Rules.html)

------
suvelx
I have used please, on a project also written by the please developers, of
which I am not.

While my experience of `plz` may have been mired by the project that used it,
I can't say I found it added anything special.

It arguably doesn't meet the needs of the `plz` developers themselves, as
evidenced by the custom build-rules in the project that overrode the built-
ins. And at one point, it was suggested to us that we drop Plz and move to
buck/bazel/pants which was suggested would be a relatively simple replacement.

Sure, it built stuff, but the general impression was it got in the way, while
due to the way it was configured, was essential to keeping the project
running.

And why are there 20 releases on the 25th of November?

------
MadcapJake
> Also we chose the domain name before almost anything else (priorities!).

I'm glad I'm not the only one with this problem :P

------
egnehots
This looks so similar to Bazel..

What's the advantage of using Please?

~~~
shoover
It's tuned to the preferences of another company; if you prefer their taste on
the finer points, that's one. Secondly, it's written in Go, so installation
should be simpler.

~~~
iainmerrick
What's hard about "brew install bazel"?

~~~
numbsafari
Why should I have to install the jdk for a build tool when I’m not using Java
myself?

~~~
abiox
i don't notice people complaining about needing ruby, python, perl or other
things installed for a given tool that depends on them nearly as much as java.
interesting.

~~~
zaarn
I actually do (internally) complain when some tool uses python/perl/ruby. It's
usually painful to install and maintain compared to most C or Go in this case.

Especially virtualenvs are an axe I like to grind.

------
alexeiz
When it comes to a build system with Python-like syntax, I prefer Waf
([https://github.com/waf-project/waf](https://github.com/waf-project/waf)) to
the rest of the competing solutions. It's written in Python, provides
excellent support for many build scenarios, but can be extended with Python
scripts without any restrictions, and has minimal dependencies (literally, you
can supply Waf packed binary with your project and it'll work on all major
platforms that have Python).

------
bfrog
Meson and Ninja being adopted by gnome is game changing

------
ball_of_lint
I dislike that the only way they list to install is "curl
[https://get.please.build](https://get.please.build) | bash". I know it's fast
and easy but it really leaves your computer at their mercy.

~~~
staticassertion
How? It's over HTTPS, and you're already trusting them to execute code on your
system... and it's not even root...

I see no way in which this "leaves your computer at their mercy" more than any
other process of purposefully executing code they control on your system.

~~~
merlinsbrain
I agree with the point you’re making and you clearly know what you’re talking
about but:

I would caution you to use the phrase “no way in which” when discussing
security - the less informed may read this and believe it.

While an edge case and requiring a mailicious targeted attack in this case
there’s at least the possibility of being MiTM’d.

The problem - as you’re probably aware - with using absolute terms when
speaking about a case like this is that it’s easy to extrapolate this sense of
safety to something that may lead to an attack that requires much less
precision thank convincing the browser that the MiTM proxy is “please.build”.

~~~
ktta
>the less informed may read this and believe it.

What they should be doing is to understand what's actually going on.

Once you download and run software from a TLS enabled website, you're putting
trust in that website. It doesn't really matter if you are doing 'curl
[https://example.com](https://example.com) | bash' or downloading a binary.
They can't be MITMed any more so with the curl way than downloading a binary.

That's all there is to it. I realize there are many security people who advice
against doing the curl thing, but I feel people should realize it is a rule of
thumb with unsecured websites.

~~~
merlinsbrain
Completely agree that they should understand what’s going on however:

It’s sometimes easy to forget that there are various reasons people are less
informed. For people early in the career for example, reading security advice
on HN and believing it is not unheard of especially when you have real experts
on here who know what they’re talking about.

Something that is “all there is to it” for you is not necessarily the same for
someone else. I’m not saying it’s anyones job to inform them; just that it’s
better not to speak in absolutes.

If security folks say something, I assume there’s a good reason until I become
a security folk myself - it’s one of those fields where being sceptical about
everything third-party helps.

My point really wasn’t about the MITM but a there’s always a possibility that
a proxy on a public/compromised network can intervene between you and a
“secured” website.

Binaries can be verified with checksums to make sure that the artifact hosted
on the repository is indeed what you received. You are 100% correct that you
are still trusting the code from the third party developer though!

~~~
ktta
>My point really wasn’t about the MITM but a there’s always a possibility that
a proxy on a public/compromised network can intervene between you and a
“secured” website.

Same can happen to a binary.

>Binaries can be verified with checksums to make sure that the artifact hosted
on the repository is indeed what you received

Here's the problem. The checksum is usually on the same page the binary is
located. Which pretty much defeats the purpose.

~~~
merlinsbrain
I see, and this was your original point.

I guess the only threat there (that I can see) is that the install script can
be malicious, but your point was that you’re trusting the owners of the
website anyway by downloading their binary and executing their code locally.
It can be argued that it’s probably easier to ship malicious code outside the
main repository (e.g. in an install script) but I do not have a good counter
besides this weak argument.

The checksum is indeed usually on the same page and does make it useless in my
hypothetical MITM.

------
ttsda
The name is not very google friendly. It took me a bit longer than I would
have liked to find examples for my specific use-case.

~~~
_asummers
I could see them using "plzbuild" as their version of "golang", for the same
problem.

------
millstone
Apologies in advance for shitting on this, but PLEASE STOP BUILDING BUILD
SYSTEMS.

We already have a serious incompatibility problem with projects using
autotools vs CMake vs Meson vs gyp vs Boost.Build vs SCons vs BUCK vs... and
now we throw Please onto the pile.

It sucks when you find a smallish library and discover it uses an esoteric
build system whose dependencies dwarf the library themselves (cough Yoga). The
OSS community needs build system consolidation, not tacking on a 15th wheel to
the cart.

Read the FAQ, it's just bananas:

> It [Bazel] is a great system but we have slightly different goals

> We preferred [Buck] to other options available, but again we're focused on
> different goals

> we didn't think it [Pants] was the ideal fit for us at the time

"All other systems had slightly different goals or weren't the exactly ideal
fit, so rather than contribute to or extend them we poured an enormous amount
of energy into rebuilding them in a slightly different way."

Relevant: [http://www.rojtberg.net/1481/do-not-use-
meson/](http://www.rojtberg.net/1481/do-not-use-meson/)

~~~
iriei283
PRs welcome

This is awful demanding. Not entirely unexpected in tech tho

“Why don’t others fix my frustration in open source projects!” they shout with
no hint of irony

~~~
foo101
Please don't make such low-effort, insinuating, cliche comments on Hacker
News. It makes the reading experience very poor.

Consider that the parent comment author might already be making pull requests
to the projects of his interest. The snarky "PRs welcome" is therefore
unnecessary and unwelcome. Everyone here knows PRs are welcome in an open
source project. Some of us do send PRs. But whether someone sends PRs or not
has no bearing on whether one can appreciate or criticize an idea as long as
it is done in a substantive manner.

In fact, whether the parent comment author sends PRs or not is orthogonal to
his complaint that we have too many build systems that is increasing the
burden on users and maintainers. If you have something to say against this
point, please do so on its own merit in a substantive manner without
insinuations or ad-hominem attacks.

------
rajangdavis
Very cool site!

------
EtDybNuvCu
Why would I use this instead of Nix?

~~~
pknopf
Do people use Nix for building and deploying project dependencies? Example
project? Can you consume the result in a format that isn't all Nix-y
symlinked?

~~~
EtDybNuvCu
nixpkgs contains tools for building Docker-compatible container images with
`dockerTools`, and also AppImage-style standalone executables with `nix-
bundle`.

My project, as well as many other projects, ships its own default.nix for
builds. Linking an example would deanonymize this account a little too much,
but there's plenty of examples out there.

------
malkia
Please bazel, buck or pants?

~~~
iainmerrick
Since Bazel is a version of the thing everybody is copying (Google’s internal
build system Blaze) I would say Bazel is most likely the best of the bunch.

I’ve used Buck; it’s slow. I haven’t tried Pants.

~~~
malkia
I've used blaze for 2.5 years, best build system ever, but haven't used at all
"pants please or buck"

------
gelo
So err... where is C# / Mono in all this?

------
nvus
Nice work, I will try using it on my next project. 404 Not Found WinLover at
localhost.

~~~
abiox
is the 404 thing humor? the meaning is a bit unclear.

------
funkythingss
this looks very interesting! Has anyone used it before?

~~~
lolikoisuru
>well I tried but they dont have samples so I gave up, no point in spending
hours in reading docs and setting up something for a build system that may be
useless. It also seemed suspiciously identical to bazel with really no
features that may be special in any way? I mean really, why use this and not
just bazel. The webpage doesnt even say

I agree with this guy. It shouldn't be that hard to include an example of an
advanced script.

[https://www.gnu.org/software/make/manual/make.html#toc-
Compl...](https://www.gnu.org/software/make/manual/make.html#toc-Complex-
Makefile-Example)

------
pjjw
favorite thing about it is their use of the pragmatapro font on the website

------
dingo_bat
Is there a problem with cmake? Why are people still inventing new build
systems?

~~~
flohofwoe
cmake cons (IMHO):

\- the archaic custom scripting language (that's its main problem)

\- there are many ways to do the same thing, resulting in each (non-trivial)
build script looking different

\- for the above reason, importing dependencies written by somebody else is
non-trivial, and its often better to rewrite the cmake scripts completely

\- it lacks some 'integration features' found in more modern systems like
Rust's cargo: (1) proper dependency/package management (2) run targets (3)
switching between build configurations should be easier (not just
release/debug, also different build target platforms)

cmake pros (also IMHO):

\- can generate IDE project files (that's what most new build systems
completely ignore)

\- very good cross-compilation support

\- describing a simple build is reasonably simple

\- broad support for build tools and IDEs

~~~
ihnorton
Microsoft (both vscode and studio) seems to be moving toward ide adaptation —
parsing output from other compilers, supporting compilation databases and
folder-only (non solution) projects. Perhaps this, combined with Clang
viability for MSVC ABI, will reduce the impetus for cross-platform projects to
use cmake just to support Windows. Of course, there’s added inertia in favor
of cmake due to LLVM, Boost, and others moving over. Not to mention that
Microsoft now also supports the “cmake server” concept (there will be some
deep irony if after 20 years of “we need cmake to support Microsoft” the
argument for the next N years becomes “we should use cmake _because_ Microsoft
supports it”).

