Compiler extensibility about sdk HOT 8 CLOSED

👍

from sdk.

At some point we're also going to need to look at how compilation options are specified. Compilers may have their own options they want to provide, etc. Perhaps in that case an intermediary is used (i.e. dotnet-compile-[lang]) which parses the project.json itself.

from sdk.

Jared and I briefly discussed this before he left.

I think we want two sets of arguments here: 1) some "compilationOptions" which are portable and 2) some "extra options" that are passed directly to the compiler.

The idea is that we want to keep familiarity by keeping the common options the same, but also provide a mechanism to provide compiler-specific and langauge-specific options.

from sdk.

The common options would be parsed by dotnet-compile, then passed on as command line arguments to the dotnet-compile-[lang], along with the extra options which are just copied verbatim.

from sdk.

Sounds like a plan!

from sdk.

Wood also be great if we didnc# sooner than later

from sdk.

@agocke @jaredpar We need to figure out how to handle source files resolution. Today we have 3 hard coded globbing patterns that look at source files:

https://github.com/dotnet/cli/blob/master/src/Microsoft.DotNet.ProjectModel/Files/ProjectFilesCollection.cs#L14-L17

Ideally this would be handled by the compiler or maybe it requires more metadata somewhere. This library will also be used for the IDE experience so it needs to flow properly and can't only be in the command line invocation (I'd rather not have the IDE do what it does today for csc 😄)

from sdk.

This is probably done. Opportunistic close. Reopen if needed. Fixed by dotnet/cli#102.

from sdk.