Skip to content

Allow source files and summaries to come from anywhere #27264

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

Closed
vsmenon opened this issue Sep 6, 2016 · 7 comments
Closed

Allow source files and summaries to come from anywhere #27264

vsmenon opened this issue Sep 6, 2016 · 7 comments
Labels
dev-compiler-ux type-enhancement A request for a change that isn't a bug web-dev-compiler

Comments

@vsmenon
Copy link
Member

vsmenon commented Sep 6, 2016

From @nex3 on July 28, 2016 0:36

Currently, all source files and module summaries must be within the build root and module root, respectively. This seems like an unnecessary limitation, and it's contrary to how other Dart implementations work.

This is blocking dart-lang/test#414. The test runner needs to synthesize an entrypoint in a temp directory, which isn't in the default build or module root. We can't even use the filesystem root, because on Windows the temp directory may be on a different drive than the Dart sources.

Copied from original issue: dart-archive/dev_compiler#612

@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

From @jmesserly on July 28, 2016 4:55

@vsmenon - would you mind taking this one? I think you're likely most familiar with the "build root" "module root" options.

@nex3 - if this is blocking, does marking it P1 sound right to you?

@vsmenon vsmenon added web-dev-compiler dev-compiler-ux P1 A high priority bug; for example, a single project is unusable or has many test failures type-enhancement A request for a change that isn't a bug labels Sep 6, 2016
@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

From @nex3 on July 28, 2016 18:58

@nex3 - if this is blocking, does marking it P1 sound right to you?

I'd appreciate it, yeah!

@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

@nex3 The build root and module root affect the generated code - the library names and module names in the generated code.

But those could point elsewhere. E.g.,

 dart ~/git/ddc/bin/dartdevc.dart compile --library-root /Users/vsm/tmp/ -o hello.js /Users/vsm/tmp/hello.dart

Is that sufficient or are you compiling multiple Dart sources from different directories in the same compile command?

If the latter, we could allow these to be a list of paths instead. E.g., something like:

dart ~/git/ddc/bin/dartdevc.dart compile --library-root /Users/vsm/working:/Users/vsm/tmp/ -o hello.js /Users/vsm/tmp/hello.dart /Users/vsm/working/world.dart

@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

From @nex3 on July 29, 2016 0:44

Is that sufficient or are you compiling multiple Dart sources from different directories in the same compile command?

I am, yeah—and in general it seems like this is a thing we should support.

If the latter, we could allow these to be a list of paths instead. E.g., something like:

dart ~/git/ddc/bin/dartdevc.dart compile --library-root /Users/vsm/working:/Users/vsm/tmp/ -o hello.js > /Users/vsm/tmp/hello.dart /Users/vsm/working/world.dart

This would work (although colon-separated reads weird to me; I'd prefer comma-separated or just being able to pass multiple --library-root flags).

How would this work if multiple sources had the same paths relative to their respective roots?

@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

This would work (although colon-separated reads weird to me; I'd prefer comma-separated or just being able to pass multiple --library-root flags).

Yeah, using comma's elsewhere already.

How would this work if multiple sources had the same paths relative to their respective roots?

It could take the first match it finds (in the listed order a la PATH). Or the tightest match I suppose.

@vsmenon
Copy link
Member Author

vsmenon commented Sep 6, 2016

From @nex3 on August 4, 2016 0:46

In #619, I wrote up a description of what my preferred replacement for --module-root and --library-root would be. I think if that lands it would obviate the need for this, but it's not the only way to solve this.

@vsmenon vsmenon removed the P1 A high priority bug; for example, a single project is unusable or has many test failures label Jan 6, 2017
@nex3
Copy link
Member

nex3 commented Jun 28, 2017

I'm closing this in favor of #27262, which seems to be a popular solution.

@nex3 nex3 closed this as completed Jun 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dev-compiler-ux type-enhancement A request for a change that isn't a bug web-dev-compiler
Projects
None yet
Development

No branches or pull requests

2 participants