Live data from Hacker News

Please – A Cross-Language Build System

please.build

71–80 of 122 posts

Re: Please – A Cross-Language Build System

#73

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 O…

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

I hear you. Building this was really hard work. Open sourcing it is an achievement: the team had to navigate fraught corporate politics, untangle internal dependencies, etc. Technically it's excellent, no doubt. The site is appealing and convincing: legit kudos to whoever designed and built it.

Maybe Please is so dramatically better that it pulls tons of projects into its orbit! What a great outcome: I'd contribute PRs for every missing use case, accelerating the consolidation.

But if (as the site says) the goal is building something at parity but with a slightly different focus, then it can only produce further fragmentation. Projects that adopt Please inject dependencies on random S3 buckets and .bashrc edits. I can't accept that in the software I maintain, so any Please-built projects are de-facto inaccessible. That's bad.

By all means do what's best for ThoughtMachine, but publishing and promoting this makes building OS software harder, not easier.

Re: Please – A Cross-Language Build System

#74
post #70

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 Makefil…

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

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.

Re: Please – A Cross-Language Build System

#75

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

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.

Luckily it's not root. Now it can only delete my entire $HOME!

Re: Please – A Cross-Language Build System

#76
post #60

Earlier quoted context omitted.

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

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.

python is generally preinstalled on all distributions i know of, because its needed for some utility applications.

ruby on the other hand gets quite a bit of flack as well, because most distributions are so far behind the official ones. that's probably why an embedded ruby binary has become a thing.

Re: Please – A Cross-Language Build System

#77
post #55

Earlier quoted context omitted.

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

Are you opposed to java, or to installing being more than one step?

Perhaps OpenJDK can be installed locally by Please when not detected in $PATH?

Re: Please – A Cross-Language Build System

#78

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 O…

Could you please not use uppercase for emphasis, regardless of how much build systems annoy you? It's basically yelling, and the site guidelines ask you not to: https://news.ycombinator.com/newsguidelines.html.

Re: Please – A Cross-Language Build System

#79
post #6

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

waf continues to be the underappreciated gem in this space: high level build language supporting many languages and tools, cross platform, implemented and extensible in Python, nothing to install (except Python), and fast.

It is quite fast and Python is a nice language for specifying the build, but I found waf to be difficult to extend.

I had some tests that needed a binary file. That binary file was generated from a text file by a utility program. That utility program had to be built from source.

After a week of trying to get that correctly specified, I gave up. I thought I'd found the right way of doing it several times, but each time I discovered the dependency chain was broken in some way. I looked into how official modules that dealt with generated files were implemented, but I found them to be surprisingly complex.

By comparison, it was only mildly annoying to do that sort of thing in CMake (the build system I moved to after a year or two with waf). The relative simplicity of CMake was what convinced me to switch.

That being said, it's been several years since I last used waf. It may have improved during that time.

Post reply on HN