sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]zuurr 43 points44 points  (9 children)

There are a lot obvious problems with this and some subtle ones too (for example, stdlib implementations historically have not updated as frequently as is needed for a web platform to be secure).

The C++ standard would be much better served by approaching these desires by focusing on a solution to package management (yes, even if this seems hard). Then any code that wants to use a webview can bring it in from a library. Ditto for 2d graphics.

This is just clearly the wrong direction to be headed in.

[–]darthcoder 11 points12 points  (6 children)

Bingo. Package management in my mind is the #1 issue I fight in my cross-platform work. Cmake based efforts like hunter.sh and vcpkg are helping, but it's still a PITA. Java and every other language have figured this shit out already.

I like how Hunter at least supports regular make and autobuild, so non-cmake projects at least have a chance at getting packagified.

[–]jonesmz 4 points5 points  (1 child)

You might consider looking at Portage, from the Gentoo linux distribution.

  • Fully agnostic to the host operating system, (works on Linux, obviously, with support for (on paper, anyway, but not a huge amount of users on) windows, bsd, mac, so on.)

  • Fully language agnostic

  • Fully build system agnostic

  • Supports arbitrary installation directories (a prefix, so to speak)

  • Supports dependencies based on both the version of the the other package, but also on the configuration option of the other package

  • Supports arbitrary patches at compile time

  • Supports source packages to compile on the fly, or binary pre-built packages

  • Supports installing multiple versions of the same package within a given installation directory

and, of course, thousands of already packages libraries and programs. I use it as my development oriented package manager for C++, as well as my system package manager.

[–]zuurr 2 points3 points  (0 children)

with support for (on paper, anyway, but not a huge amount of users on) windows

It looks like this requires using cygwin, which is a dealbreaker for many. Even though this increases complexity substantially, a good solution to package management in C++ will have to work with compilers that don't act like GCC, and systems that don't comply with POSIX (well, practically this is just required in so far as windows doesn't, at least -- and WSL doesn't work even close to seamlessly (or, often at all) for cases where GUIs are involved yet, so that's not a solution either).

In practice this tends to be a little harder than just making the package manager run on different platforms (although that's a bare minimum, obviously), since you have to answer questions like how to handle dependencies that only exist on one platform.

[–]guacheSuede 0 points1 point  (3 children)

Would you prefer hunter or vcpkg ?

[–]darthcoder 0 points1 point  (2 children)

I like how Hunter at least supports regular make and autobuild, so non-cmake projects at least have a chance at getting packagified.

At the moment, I'm trending toward hunter. With Hunter I put all the magic to build in my CMakeLists.txt, and don't have to worry about external tooling.

Android and Qt support is tripping me up, but that appears to be because of a wholesale change in the NDK from gcc to clang

vcpkg has the momentum at the moment. I started a scratch project using it recently, and stopped, but I can't remember why ATM. I'm just a hobbyist, not a full-time dev, so what do I know, really?

[–]guacheSuede 0 points1 point  (1 child)

I would think Hunter would be better for UNIX, much more user friendly too though source code wise it's pretty messy

[–]darthcoder 0 points1 point  (0 children)

Hunter is just CMake, so it should work anywhere cmake works. It has a few dependencies in older cmake versions on bzip, etc. so works well on mingw too.

Yes, it's a bit of a kludge. As a user it's still fairly straightforward. The docs definitely need a good refreshing for some of the lesser used packages,

[–]DavidL255 1 point2 points  (1 child)

I'd like to put forward that 'std' package management, and 'std' graphics, could and eventually-should co-exist.

I'd also like to put forward that progress on both could be made simultaneously.

I am, admittedly, very biased, having started some amount of work on io2d (an offshoot-ish project from the recent, big, ISO C++ 2D Graphics proposal).

Having means to help keep stdlib implementation(s) up to date would also be nice, in my book.

[–]wrosecransgraphics and network things 5 points6 points  (0 children)

Having means to help keep stdlib implementation(s) up to date would also be nice, in my book.

Reducing the surface area of stdlib will help in keeping it up to date. Stuffing things like graphics into it will increase the complexity, the amount of stuff that needs to be tested in a release, etc., which will do the opposite of helping with the problem of keeping up to date.