
Proposal for a packaging system for C++ [pdf] - adamnemecek
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0235r0.pdf
======
TheAceOfHearts
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](https://github.com/substack/dotc)

~~~
yoklov
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.

------
kitd
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.

~~~
kelvin0
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..."

~~~
devbug
_shudder_

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

~~~
shadowfox
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/](https://msys2.github.io/)

------
ycmbntrthrwaway
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.

------
imglorp
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.

~~~
acveilleux
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.

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

------
Joof
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.

------
joelg236
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).

------
fungos
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](https://github.com/floooh/fips) (and yes, I
know about CPM, Biicode, Conan, Hunter, etc..)

------
frankzinger
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).

------
davexunit
Oof, not another language package manager.

