logoalt Hacker News

looneysquashtoday at 5:05 PM1 replyview on HN

Nice. I have been thinking of making something similar. Now hopefully I don't have to!

Not sure how big your plans are.

My thoughts would be to start as a cmake generator but to eventually replace it. Maybe optionally.

And to integrate suppoet for existing package managers like vcpkg.

At the same time, I'd want to remain modular enough that's it's not all or nothing. I also don't like locking.

But right now package management and build system are decoupled completely. And they are not like that in other ecosystems.

For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.


Replies

psyclobetoday at 5:11 PM

> For example, Cmake can use vcpkg to install a package but then I still have to write more cmake to actually find and use it.

I have this solved at our company. We have a tool built on top of vcpkg, to manage internal + external dependencies. Our cmake linker logic leverages the port names and so all you really do is declare your manifest file (vcpkg.json) then declare which one of them you will export publicly.

Everything after that is automatic including the exported cmake config for your library.