Add ability to set extra tokens in settings

[piepie62]

An implementation of the suggested solution to the problem solved by #649 in lieu of adding environment variable parsing to asconfig.json

[piepie62]

Actually, quick question: would environment variable parsing for these tokens' values (probably using standard VS Code syntax, ${env:VariableName}) be accepted?

[joshtynjala]

If ${env:VariableName} can be used in settings.json, then asconfigc should receive the full path without any special extra parsing.

[joshtynjala]

I probably won't have time to properly test and merge this soon, but I took a quick look over the changes, and everything seems exactly like how I would implement it. That should make things easy once I can dedicate some time to it.

[piepie62]

If ${env:VariableName} can be used in settings.json, then asconfigc should receive the full path without any special extra parsing.

Problem here is that it doesn't necessarily seem to; I tried doing that and it doesn't work properly. I would need to explicitly handle that, unless I'm simply missing something that would enable that automatically

[joshtynjala]

I doubt that you can do anything to enable environment variable parsing in settings, if it doesn't work by default.

In this case, you may not be able to use environment variables. That's fine for your use-case, though. You just wanted it to be possible for developers on different machines to reference different paths. Since settings are local and not shared, that's possible without environment variables.

[piepie62]

I've just also locally implemented tasks setting their own additional defines and additional compiler arguments. I figure that it could fit here, and the changes would conflict on a separate branch as well; would that be something you're interested in?

[joshtynjala]

I've just also locally implemented tasks setting their own additional defines and additional compiler arguments. I figure that it could fit here, and the changes would conflict on a separate branch as well; would that be something you're interested in?

No, I don't think so. Changing compiler options for different builds is what asconfig.whateveryouwanthere.json is meant for.

[piepie62]

I think I agree with that in theory but given that there are debug settings for tasks that doesn't quite work; a define for config vs release would have to have a asconfig.debug.json (or .release., whichever), which doesn't seem like a good solution to me.

[joshtynjala]

After seeing it implemented in TypeScript with tsconfig.json, debug vs release is actually the primary reason I added support for asconfig.release.json, so it's interesting that you mention that debug vs release is an issue. Haha!

[piepie62]

Ah. In that case I don't understand the point of the debug option for tasks; either way it seems inconsistent currently.

[joshtynjala]

Not all projects need different compiler options for debug vs release. So, having separate debug and release tasks makes perfect sense when you're using only asconfig.json, and you don't need any other asconfig files. However, if you need to provide different compiler options for debug vs release, then it's great that you can create asconfig.release.json and have it extend asconfig.json (or create separate asconfig.debug.json and asconfig.release.json files, if you prefer). Yes, you'll get separate debug and release tasks generated for each additional asconfig file too, but that doesn't mean that you're required to use every task that's available to you.

Of course, you don't need to use asconfig to distinguish between debug and release only. It could also be used for desktop vs mobile, or even more granular with Windows vs macOS vs Linux vs iOS vs Android. I love that flexibility.