Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please – A cross-language build system

please.build

Post reply on HN
Print view View original

171–180 of 257 posts

Re: Please – A cross-language build system

#171

Post by skulk »

high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (though I have no idea whether please fulfills this)

Re: Please – A cross-language build system

#172

Post by hobofan »

high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human"

I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

Re: Please – A cross-language build system

#173

Post by patrec »

jedberg wrote: post #93
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?

I think one good way to think about it is all of these build systems create Make environments. They create the makefiles and have all the other tools that go with it. So at the end of the day you end up with an executable artifact, but hopefully you did a lot less work to get there.

Only garbage like autotools or CMake generates Makefiles, all remotely sane build systems (including the various bazel/blaze derivatives) do away with make, which even sucks as a low level abstraction.

Re: Please – A cross-language build system

#174

Post by damnyou »

skulk wrote: post #171
high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

Are build systems typically CPU bound, even during heavy operations such as calculating dependency closure (or other things I'm unaware of)? If not, the I don't see a need to use a language that doesn't provide high level, somewhat costly, but easy to use and understand abstractions. And if it's faster than its competitors and it weighs less, then there's also nothing wrong with calling it "fast" and "lightweight" (t…

Build system performance tends to be IO-bound, but responsiveness for things like no-op builds tends to be CPU-bound -- and the JVM in particular really suffers. Optimizing IO performance makes it perform better, while optimizing CPU performance makes it feel better to use.

Arguably, making tools feel better to use is more important than raw performance. When you're doing a no-op build, the difference between 100 milliseconds and 500 is large, and the difference between 10ms and 100 is enormous.

Re: Please – A cross-language build system

#175

Post by Ericson2314 »

rhencke wrote: post #121
wpietri wrote: post #107

Earlier quoted context omitted.

That's only true if you define software development in a pretty particular way. For me, writing code is a way of solving problems for people. That involves listening to them to see how I can help. Then collaborating with them to iteratively make something that fits their needs. Which includes helping them adopt it and get productive with it. To me, all of that is part of software development. And that's most of the "…

To me, writing code is very much the same way - it is a human endeavor. But, over the years, I have learned that just not all people are the same way, and that's okay, too. Growing up, one of the jobs I took was as a system's administrator at the same company my father worked at. It was a small company, maybe six people or so, doing contract work for aerospace. One of the older men who worked there held his Ph. D. in…

That's totally fair. But...going on a hunch, such a person would also make a crude 90s-style website.

Whoever made this clearly knows about slick presentation --- they've got all those colors and shapes pizzas --- so they either capable with slick communications, or work with someone who is. My patience for lack of explanation is therefore a lot thinner.

Re: Please – A cross-language build system

#176

Post by RangerScience »

BerkhanBerkdemi wrote: post #129
ironmagma wrote: post #78

Earlier quoted context omitted.

Are you referring to this [1]? I had to click Documentation to get here and still didn’t see any code... [1] http://sinatrarb.com/documentation.html

I think he was referring to the Intro page [1][2]. [1] http://sinatrarb.com/intro.html [2] https://github.com/sinatra/sinatra#readme

I was referring to the landing page: http://sinatrarb.com/

Re: Please – A cross-language build system

#177

Post by moonchild »

haberman wrote: post #155
moonchild wrote: post #142

Earlier quoted context omitted.

> 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. > The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." This is wrong. Even ninja has generic rules. Here's an example of a minimal makefile: OBJ = src/a.o src/b.o src/c.o libfoo.so:…

> Here's an example of a minimal makefile: Your example does not contradict what I wrote. You manually specified the tool to be run ($CC) and all of the arguments to that tool. It's true that there is a level of indirection through the $CC variable, but you're still operating at the level of specifying a tool's command-line. > There's no reason this shouldn't be possible with make; it just hasn't been implemented so.…

> You manually specified the tool to be run ($CC) and all of the arguments to that tool

Notably, I didn't specify the arguments to be used to compile the source files. But if you insist:

  linklibrary = $(CC) -shared -o $1 $2

  libfoo.so: $(OBJ)
          $(call linklibrary,$@,$(OBJ))
Notably, linklibrary can be defined according the platform, or according to dynamically set variables, giving you the same level of flexibility as make.

>> There's no reason [sandboxing] shouldn't be possible with make; it just hasn't been implemented so.

> Make is 44 years old. If it were an easy extension to the existing paradigm, there has been ample time to implement such an extension.

‘Nobody's done it yet, ergo it's not possible or easy’ is not a valid argument.

> just one example, any header that is conditionally included (behind an #ifdef) could cause this cache to be invalidated when CFLAGS change, but Make has no idea of this.

Then you specify that the source files depend on the makefile.

Re: Please – A cross-language build system

#178

Post by rhencke »

liuliu wrote: post #160
rhencke wrote: post #68

Earlier quoted context omitted.

As someone who has had to run and maintain build systems for several (sadly far too) large projects (5MLoc+), I want a product that sells me on how easy it is to create _correct_ builds, and how impossible it is to create incorrect ones. So much wasted time goes into diagnosis of incorrect results from incremental builds that most people who implement CI systems never use incremental builds, and always build from scr…

Incremental builds with the said tools (Please, Bazel) should be a non-issue due to emphasis on hermetic build from these tools.

Unfortunately, reality is messier than this. For example, Please currently has escape hatches that can be used that nullify these guarantees. What I have found is that if such a mechanism exists it will eventually be abused.

My perspective here is specifically from that of a maintainer of large builds where the code base is always under active development. Murphy's law becomes your enemy at scale.

This is not a criticism of Please - just an observation that as an industry we are not there yet. But, I'm happy to see things moving in the right direction.

Re: Please – A cross-language build system

#179

Post by erik_seaberg »

sercand wrote: post #153
klodolph wrote: post #116

Earlier quoted context omitted.

And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…

Good to know that you live in a privileged place and access a fast internet connection. Most of the places don't have that kind of bandwidth [1] to download 600 MB of file in 40 seconds. Also, Bazel needs a huge amount of RAM because of JVM and runs a daemon process in the background to speed up the build duration. Running a background JVM daemon process is a NO for me and Bazel wastes system resources. [1] https://e…

That 600 MB is mostly standard library, and reusing it makes every app smaller. Statically linking everything creates size and version skew problems that I hoped we had left behind in the 1980s.

Re: Please – A cross-language build system

#180

Post by eeZah7Ux »

hobofan wrote: post #172
high_priest wrote: post #165

I personally despise people combining terms like "fast" or "lightweight" with languages like Go and Python. We are looking at a build system that, to my knowledge, doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human". When I see someone giving such reasons for not using a more performant language, I immediately associate such project with janky, fast writte…

> doesn't take any advantage from being written in Go, other than "being easier to write and understand by a human" I would assume that is has the same advantage as most other Go programs: It's easily distributed as a single static binary, and doesn't need a heavy runtime to be installed.

No thanks, I want my binaries to use shared objects so that an entire OS can receive quick security updates.

And I want the binaries properly packaged with metadata, documentation, manpages to keep the host secure and tidy.

Post reply on HN