microsoft / BuildXL

Microsoft Build Accelerator
MIT License
917 stars 146 forks source link

SDK not getting fully packaged #1277

Open ScatteredRay opened 4 years ago

ScatteredRay commented 4 years ago

Hi, I'm trying to use BuildXL external to Microsoft, and given the lightness of the documentation I've been running into a lot of confusing areas, one such area is the Sdks directory.

So, it appears to me that Sdks is supposed to be the dscript binding of a lot of internal functionality, is that correct?

So, to even get access to Sdk.Transformers, it seems that I have to:

  1. Install BuildXL as a sub-directory to my project,
  2. Set an environment variable so I have access to that directory: i.e. $env:BUILDXL_BIN=(Get-Item ".\Microsoft.BuildXL.win-x64.0.1.0-20200711.0").FullName
  3. add something like f`${Environment.getPathValue("BUILDXL_BIN")}/Sdk/Sdk.Transformers/package.config.dsc`, to my config.dsc.

So, that already seems suspect, so let me know if I'm just misunderstanding the setup, but this comes mostly from the HelloWorld example project, and seems to be the only real example of doing a DScript build.

So, the problem is, now when I try to use any additional functionality, such as Json, I run into some problems.

I try to import from Sdk.Json import * as Json from "Sdk.Json";

And I get the error: [0:03] error DX11230: C:\Temp\SetupBin\Git.Package.dsc(2,23): No resolver was found that owns module 'Sdk.Json'. Known modules are: [Sdk.Transformers, git.package], [Sdk.Prelude]

So, as I look into the distribution, the vast majority of the Sdk directory does not seem to be included, is that intentional? Is it intended I import the Sdk into my project?

Additional samples of using advanced functionality in DScript would greatly improve the experience of working-out how to properly use BuildXL.

ScatteredRay commented 4 years ago

This seems true of both the nuget build from https://pkgs.dev.azure.com/ms/BuildXL/_packaging/BuildXL/nuget/v3/index.json and from a locally deployed build at C:\Users\indy\Telltale\BuildXL\Out\Bin\debug\win-x64

narasamdya commented 4 years ago

It seems that we need to re-work some of our examples.

Indeed, to use functionalities in the SDK, one needs to include them in the resolver (specified in config.dsc). In this way DScript can find where they are located.

We typically include everything from the %BUILDXL_BIN_DIRECTORY%, in either of these two ways:

resolvers: [
        {
            kind: "DScript",
            modules: [
                ...globR(d`${Environment.getPathValue("BUILDXL_BIN_DIRECTORY")}/Sdk`, "package.config.dsc"),
                ...globR(d`${Environment.getPathValue("BUILDXL_BIN_DIRECTORY")}/Sdk`, "module.config.dsc"),
                ...globR(d`${Environment.getPathValue("BUILDXL_BIN_DIRECTORY")}/Sdk`, "module.config.bm"),
            ]
        },
    ],

or

resolvers: [
        {
            kind: "DScript",
            root: d`${Environment.getPathValue("BUILDXL_BIN_DIRECTORY")}/Sdk`,
        },
    ]

You can also take a look into how we set up/structure our integration tests here. In the tests we build a number of modules.

ScatteredRay commented 4 years ago

But it still seems that many SDK functionalities aren't included in the build, such as jsonSDK.dsc?

smera commented 4 years ago

Only the very basic SDKs are bundled together with BuildXL binaries. Those are the SDKs you see under <bxl-install-dir>/Sdk.

All SDKs (bundled with bxl binaries or not) that are needed have to be explicitly referenced from the main config.dsc file under 'resolvers', as the example Iman was showing above. A module.config.dsc (or package.config.dsc, the old name for module files) is what declares a particular module. If a module file exposes a module 'Foo' then referencing this module file in the main config will enable expressions like 'import * as Foo from "Foo" ' in a particular spec. The 'No resolver was found that owns...' error means that you are trying to import a module that is unknown to any resolver.

I believe at the moment we are not publicly publishing a NuGet with the additional SDKs. This is something we can consider doing. But if you clone BuildXL repo, you'll find all public SDKs here, you can just point your main config file resolvers to the module files you are interested about