Closed omsmith closed 5 years ago
Relevant to #7 (and #8 I guess).
Cool. It's going to be interesting getting these wired into the @net
targets :P
total nit: maybe some private helper macros to separate the different packages a bit
So I'm thinking we check in a bunch of BUILD
s relevant to each package? Check them in so we can generate deps
correctly.
I still think it'd be good to wire these into @net
targets eventually to make multi-targeting easy (e.g. at D2L we'll want to multi-target .NET framework and standard for some DLLs as we do that conversion... being able to just reference @net//:System.Linq
in all contexts seems key to make life sane). What do you folks think? (CC @jimevans - btw I sent you an invite for write access to this repo).
total nit: maybe some private helper macros to separate the different packages a bit
Can you expand on that one a bit?
Oh sorry, yeah that's unclear. I meant a helper function like _netstandard_repositories
... but then there is overlap with .NET Core and maybe csharp_repositories
should just be a big alphabetical list of packages anyway. Let's ignore that comment :P
Cool! Keeping these up-to-date will be an interesting challenge :)
Cool! Keeping these up-to-date will be an interesting challenge :)
Yeah, can probably build a tool to walk the dependency tree of a package for a set of tfms and output the rules.
TODO:
I didn't list
Microsoft.NETCore.Platforms
because I wasn't sure if anything actually depended on it for realsies (easily addable once we try to actually use these?). I also didn't listMicrosoft.NETCore.Targets
, since I assume it's just msbuild targets.