-
Notifications
You must be signed in to change notification settings - Fork 146
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
Comments
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 |
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 We typically include everything from the
or
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. |
But it still seems that many SDK functionalities aren't included in the build, such as jsonSDK.dsc? |
Only the very basic SDKs are bundled together with BuildXL binaries. Those are the SDKs you see under 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 ' 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 |
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:
env:BUILDXL_BIN=(Get-Item ".\Microsoft.BuildXL.win-x64.0.1.0-20200711.0").FullName
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.
The text was updated successfully, but these errors were encountered: