docker-library / buildpack-deps

MIT License
445 stars 113 forks source link

add gcc variant #17

Closed proppy closed 8 years ago

proppy commented 9 years ago

based on the discussion on https://github.com/joyent/docker-node/pull/2#issuecomment-71506264 adding a -gcc variant that could share between language stacks with a C API.

The goal of the variant is to include just enough bytes to cover building native package:

tianon commented 9 years ago

You still haven't clearly defined where we draw the line for this variant, though.

tianon commented 9 years ago

For example, I would personally be very surprised to find that this doesn't include g++, and that personal expectation is going to be different from user to user.

proppy commented 9 years ago

@tianon will update the description.

proppy commented 9 years ago

@tianon I think adding g++ make senses, since some module might be written in C++ with extern "C" symbol to interop with the runtime.

yosifkit commented 9 years ago

What about the rest of build-essential that come as recommends (which is just manpages manpages-dev if we ignore the items for making debian packages)? Where do we draw the line?

This issue is related to #16.

proppy commented 9 years ago

Yes, build-essentials without the debian stuff sounds a fine line to draw for me.

Maybe dropping the --no-install-recommends would make more sense here.

tianon commented 9 years ago

That's great but it's all feelings and impressions. How do we unambiguously state that "this is what's OK to be included" without it being based entirely on our personal feelings for what's "too much" ?

proppy commented 9 years ago

@tianon what do you think for the updated description?

The goal of the variant is to include just enough bytes to cover building native package

The goal should be that if you include a python, node or go package in requirements.txt, packages.json or import that has some C code in it, it should not fail because you miss some elements of the native toolchain.

tianon commented 9 years ago

I think "building native package" is still subjective. I don't think it's at all far-fetched to imagine Python or some other language growing support for native modules written directly in Go. Similarly, what does this mean for LLVM and friends?

proppy commented 9 years ago

@tianon maybe a better way to phrase that would be npm install or pip install or go get should not fail because you miss a tool. Many languages have a document C/API, with clear hook in their build system. The goal here is to define the common set of tool they expect to be there to produce native extension.

yosifkit commented 8 years ago

Closing stale PR. Most users want something tiny, like an alpine-based image, or want it just to work, like the default language images; shared layers isn't really a concern for most users.