[Scons-dev] Adding SCons support for VCPkg

[Bill Deegan]

Ryan,

Interesting project.
Likely something more generic (with per platform logic) might be optimal.
That said we might not want to throw away the good waiting for the perfect..
I believe other build tools have similar existing functionality, so this
could certainly be an interesting feature to add.

SOURCE:
Am I safe in assuming the source would be a github repo?
Or could it also be a zip file you download?  Would you specify the
version/branch/tag for such?
Would you want newer versions to be retrieved as they are published?

TARGET:
I think you'll have to list at least all the files which other parts of the
build could depend on.
So headers, sources, libraries, data files?

Re bootstrapping:
Can vcpkg be installed via chocolatey?
I'm thinking minimally the default should not be to download and bootstrap,
but an optional flag could indicate to do so.
Thought it could get pretty messy.
Almost too bad vcpkg doesn't include a sconscript.. that'd make it simpler
to bootstrap inside scons.

-Bill



On Sat, Mar 16, 2019 at 2:38 PM Ryan Saunders <jediry at outlook.com> wrote:

> Hi SCons developers!
>
>
>
> I am working on a SCons tool integrating the new VCPkg package manager
> from Microsoft (https://github.com/Microsoft/vcpkg). VCPkg makes it
> pretty straightforward to acquire 3rd party libraries and header
> files…”vcpkg install boost” is basically equivalent to “apt-get install
> boost-devel” on Ubuntu. Personally, I’m excited about this, as acquiring
> and configuring development libraries on Windows has been painful,
> historically. VCPkg works on Windows, Linux and MacOS (though I've only
> tried it on Windows so far.)
>
>
>
> (Note: I work for Microsoft, but not on anything related to VCPkg or
> Visual Studio…this is strictly a side project for me.)
>
>
>
> I envision it working something like this:
>
>
>
> env = Environment(tools = [‘default’, ‘vcpkg’])
>
> env.Replace( VCPKGROOT = ‘#/some/path/vcpkg’ )  # Override default root
> directory of #/vcpkg
>
> …
>
> env.VCPkg( ‘boost-smart-ptr’ )
>
> env.VCPkg( ‘FreeImagePlus’ )
>
>
>
> …possibly with some as-yet-unspecified integration with the Configure
> context, so that packages can be auto-installed if not found.
>
>
>
> Basically, my goal is to be able to “git clone” a project onto a machine
> with just Git, VS and Python installed, and then to build successfully
> (including acquiring all necessary libraries) simply by running “scons”.
>
>
>
> Some questions I have:
>
>    - Is this something that would be acceptable/desirable as part of
>    SCons core, or should I be thinking of this as a tool that lives in its own
>    repo?
>    - It occurs to me that, while this does work on Linux/MacOS, these
>    systems have their own native package management solutions for acquiring
>    development libs. So, perhaps this would be better as a sort of
>    “meta-package-manager” tool that uses VCPkg on Windows, and something
>    native-ish on other systems. On the other hand, those tools usually require
>    root access to use, so maybe that’s not a good idea. Thoughts?
>    - In my current prototype, if VCPkg is not found, then I’m downloading
>    it and building it via its “bootstrap” script. However, I’m not sure where
>    the best place to do this is…I could do it in my tool’s generate()
>    function, which seems logical, but this appears to be called immediately
>    upon loading the tool, before the SConscript has an opportunity to override
>    VCPKGROOT. What do you recommend?
>    - I’m having difficulty deciding what “source” and “target” should be
>    for my Builder.
>       - Based on scouring the ‘net, it seems that I want to use a Value()
>       as my “source”…probably just the string name of the package to be
>       installed. Does that sound right?
>       - For “target”, would it be better to exhaustively enumerate all
>       the outputs of “vcpkg install <pkg>” and list these as “targets”, or should
>       I find some single file that gets produced by installing a package (e.g.,
>       the package manifest), and use this as a “sentinel” for the whole package?
>       The latter is clearly simpler, but could this result in an incomplete
>       incremental rebuild after upgrading to a newer version of the package?
>
>
>
> Any advice you can provide would be appreciated!
>
> Ryan
>
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20190316/19d88fff/attachment-0001.html>