Proposal for a packaging system for C++ [pdf] | Hacker News Reader

Proposal for a packaging system for C++ [pdf]

open-std.org

49 pointsadamnemecek20 comments

This is exciting!

A few years ago, someone created dotc [0], which lets you use node-style require and export in C.

With that said, from skimming the document, I'm not a big fan of this variation of imports. You're dumping everything from the library into your environment. IMO, this makes it really difficult to trace code and figure out where stuff comes from.

For comparison, with ES6 you specify what you're importing and from where you're importing it:

    import * as Foo from './Foo'
    import { bar, baz } from './Bar'

When I see baz() used in my code, I know that I can look in the Bar file for its definition.

Isn't this a concern? I must recognize, though, that I've barely touched C++, so maybe I just don't know any better.

[0] https://github.com/substack/dotc

This is written by substack, who is among the most prolific (if not the most prolific) contributors to npm. Node.js has benefitted from the power of standard packaging. It is really incredible how easy it is to work in that ecosystem. Provided a solid mechanism for packaging and dependency description the same pattern should be possible in C++ as well. I look forward to that day. Things will really take off when it costs almost nothing to leverage someone else's work in a controlled way.

Partially importing symbols from a header file in C++ could easily lead to bugs due to the way that name resolution and ADL work. I think doing this in a satisfactory way would end up being extremely complicated, and adding even more complexity to how C++ name resolution works is... undesirable.

But moreover, for this to be maximally useful, it needs to work with the large set of existing C and C++ libraries.

C++ needs this more than anything else IMHO. After you've worked with D or Rust for a bit, trying to incorporate external code into a C++ project is like running your nails down a blackboard.

It's hard enough on Linux/Unix/BSD OSes ... you should try it on Windows ... fun times. Especially when the build instructions on Windows start with :

"Download and install Cygwin/Mingw..."

shudder

MinGW is alright... until you try targeting x86_64.

Msys2 [1], I have found, is a workable choice for this. It comes with a port of pacman and has a decent, but by no means comprehensive, set of packages.

[1] https://msys2.github.io/

I never had any problem with using libraries packaged into distro repositories. And I don't want C++ package manager. From my experience with other languages, it would result in lots of low-quality and poorly maintained packages used instead of established standard libraries.

On the other hand, it may be acceptable for "applications" world, as opposed to system software. Desktop applications may benefit from it, but first we need proper sandboxing to prevent low-quality libraries from undermining security.

I applaud the effort.

Nothing much has changed beyond C and the FTP-zip-tar-configure-make landscape since, what, 1980? The distro package systems have improved things a little.

This will have a bigger impact on the language than a lot of the individual library incorporation that's been going on.

configure scripts became ubiquitous in the mid nineties about the same time as Linux.

Prior to that, it was FTP-uncompress-untar-edit config.h-make.

You'd be expected to spend 10-30 minutes scanning a long config.h file or similar and adjusting as per your local unix variant. Often a BSD or SVR4 like system (rarely both) would work mostly out of the box. AIX, Ultrix, or HP-UX were more troublesome from what I can remember, SunOS or Solaris (never both ;-)) would mostly work out of the box as that was commonly the dev platform.

Ah, yes. There was also the imake/IMakefile variant too, mostly for X11 related stuff.

If people used it properly, it wouldn't really be an issue.

It's not an issue, it's a ginormous convenience.

Wouldn't you rather have one # decl that does all the legwork of installing a dependency for you, plus all the things it depends on? All these cool kids' languages have that stuff builtin now. Or at least builtin one level away, ie gem, "go get", gradle, etc and ilk. It's so convenient. I dread that part of c*.

Go live behind a firewall. See how that pans out for you.

It will encourage some horrendous levels of indirection in dependencies that cpp currently doesn't suffer from. I've been doing this for 7/8 yers and I don't feel inconvenienced. Indeed I think it represents a decent quality control step

True, there's tradeoffs there.

If the C++ standards committee isn't building it and Stroustrup isn't backing it, then it won't get adopted.

I could also see boost getting something though.

What would differentiate this from something like cmake's current package system? As far as I can tell the only advantage of something like this is if a majority of packages adopted it (like pip).

I'm slowly reading this with a lot of attention, will soon have a better idea of the proposal. Until there, take a look at this https://github.com/floooh/fips (and yes, I know about CPM, Biicode, Conan, Hunter, etc..)

Sounds like the focus here is on libraries not available in the system package manager. I.e, the goal is not to supersede the system package manager (because that would be nigh on impossible, IMO).

Oof, not another language package manager.

Reply on news.ycombinator.com