Vcpkg: Was great idea and good package - now not dependable too much maintenance

[ghost]

I didn't know where else to post this - just my opinion and experience with this package.

VCPKG at one time was a great idea, a good package and helped windows users developing with visual studio tremendously on windows platforms.

Now, with the catering to Linux and OSX builds, everyone adding their packages with each platform, the package has become too unstable, unmanageable to way too time and resource consuming.

Many times a base package changes to accommodate a new flavor of the week Linux, a new Linux or OSX option, configuration, build or link setting is added, thus incrementing the version number, but nothing on the windows side has changed, but necessitates an almost complete recompile, and that's if the change didn't break the windows build/compile/link process.

I used several hundred of the packages and when you spend a whole day or two recompiling the packages just to perform another "git pull" to keep up to day it wants you to recompile almost your complete install again - well you get the picture.

It's hard enough to port libraries/programs to run on multiple platforms, its even harder to build and maintain a program that builds/compiles and links those programs for multiple platforms.

I for one will go back to the old way of pulling the individual sources, configuring, building, compiling and linking for win64 dynamic, as that's all I need the programs for -

Notes I would like to pass along:

1. The upgrade process needs to be changed to only look at the packages installed and their triplet for changes - if the changes made does not affect/effect the package/triplet combination you have installed it should register no update required.
2. The new --clean-after-build works great, but if you do an upgrade, the vcpkg no longer cleans up after upgrading a package - there should be a flag set somewhere on a package/triplet combo that vcpkg retrieves from a file, database, etc that lets it know once it successfully upgrades a package to cleanup after it.
3. There needs to be set standards on what tools are to be used - too many are being used and some are not good players with certain platforms, notoriously windows. I'm not bashing the other platforms, I'm quit fond of *ix *ux systems, just most gaming is done on windows by the lay person.
4. Suggest breaking vcpkg up into three separate packages, or eliminate OSX and Linux altogether, after all, those other platforms already have their own vcpkg like processes that do a much better job than vcpkg on those platforms - why reinvent the wheel and stick to building something that works superb with windows.
5. More testing before commitment on GitHub - it seems a basic package build/compile/link for another platform is changed, somehow the windows platform package process doesn't like it and the package fails, and the cascading effect causes almost your whole library to be removed and not reinstalled.
6. Some of the sources or dependent package haven't changed hasn't changed for years, yet the vcpkg will be tweaked for build, compile or link setting, cmake setting, msbuild setting, etc. etc and the complete installed library has to be recompiled - why?

Much heartaches can be eliminated using the KISS method - this package has gone way beyond this thought process.

It was nice while it lasted, but it's too much work now - being the hobby game builder, I'm spending way too much time with vcpkg and no time programming or tweaking games.

Best regards and success in your continued adventures.

[Neumann-A]

Some questions:

• Why did you have the need to stay up to date to vcpkg master? (For example I only update if I want to use a new version of the ports I use. One of those examples would be the boost update to 1.7 and I expect and accept the fact that this requires a lot of recompiling.)
• How did you use VCPKG? (VS integration, CMake toolchain or other?)
• Which packages/ports are you using?

Now, with the catering to Linux and OSX builds

Most of that just comes from CMake being able to create buildfiles for those platforms.

Suggest breaking vcpkg up into three separate packages, or eliminate OSX and Linux altogether, after all, those other platforms already have their own vcpkg like processes that do a much better job than vcpkg on those platforms - why reinvent the wheel and stick to building something that works superb with windows

Reason: Same workflow on any OS. It makes it so easy to use my windows workflow on linux and I am not a guy who uses linux a lot. Especially remembering the different linux packages managers between different distributions is a pain in my point of view. Splitting them up is also not a good idea because package versions between those different vcpkg instances will diverge and would break the above workflow. I really like and depend on the unified workflow vcpkg offers.
(I am a user of the vcpkg toolchain on windows and linux)

I personally think vcpkg could add a vcpkg-<os>-subversion flag into the control file to only require the OS to recompile the package which requires it. Currently any change to the version in the CONTROL of a package requires a recompile of the package and all dependent packages but the latter is exactly what you want to have for an update although vcpkg could an os-subersion flag to finetune it.

[NNemec]

I see the same problem: vcpkg started as light-weight approach to simplify porting applications from Linux to native Windows. With the goal of supporting all different OSs, it has now become extremely complex to fix any problems within the set of ports without breaking something. I have been working on porting an application to Windows for weeks, had to add various ports and fix issues with others. Quite a number of changes were slowed down by the need to keep everything working on all platforms.

IMO, vcpkg should remain focused on Windows only, allowing the other OSs to continue using their native package management systems. Ideally, vcpkg should work as a simply drop-in replacement for the package manager without requiring changes to the application's build files. The elements missing for this are consistently installed Find*.cmake files and *.pc files. If these were installed by vcpkg for each port with the regular name, the application code could simply resolve its dependencies by one unified approach without having to know much about vcpkg.

[yamcenutzer]

I never took the linux version seriously and I also never got it to work. Since it has the same Linuxy free software quality of non-reproducability and misleading documentation.
Unfortunately all this linuxy stuff is now interfering with it's capability of being actually useful on Windows where it actually fills a gap.

[ghost]

There have been hiccups along the way, but things are definitely getting better the past few months - as it appears those making changes have been more considerate/conscientious of making changes and how it may affect the other platforms the package is already supporting.