Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDK not getting fully packaged #1277

Open
ScatteredRay opened this issue Aug 20, 2020 · 4 comments
Open

SDK not getting fully packaged #1277

ScatteredRay opened this issue Aug 20, 2020 · 4 comments

Comments

@ScatteredRay
Copy link

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
Copy link
Author

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
Copy link
Collaborator

narasamdya commented Aug 24, 2020

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
Copy link
Author

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

@smera
Copy link
Member

smera commented Sep 17, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants