opened
chicoxyzzy
username_0
Is it possible to provide another way to build HTML?

Looks like currently it's not possible to use `-o` option with file target using other tools like cargo.
```bash
$ cargo rustc --target=wasm32-unknown-emscripten -- -o wasm.html
   Compiling wasm-test3 v0.1.0 (file:///Users/Chico/Projects/wasm-test3)
warning: ignoring specified output filename because multiple outputs were requested

warning: ignoring --out-dir flag due to -o flag.
```

Would be great to have a way to do something like
```
cargo rustc --target=wasm32-unknown-emscripten -- --compile_html
```

ref https://github.com/japaric/cross/pull/36#issuecomment-270985710
Providing target option for emcc
issue
created
kripken
username_1
Currently emcc uses the suffix of the output file to know what to emit, and there isn't another way to set that. I'd prefer not to add such redundancy if we don't absolutely need to.

Can't cargo somehow pass along `-o wasm.html`? In fact in a recent issue I am pretty sure I heard someone say that that worked, but maybe I misread?
comment
created
chicoxyzzy
username_0
I think [this is the issue you mentioned](https://github.com/WebAssembly/binaryen/issues/867).

However there is still no way to do it using cargo. It's only possible using rustc
comment
created
kripken
username_1
Oh, ok. Sorry, I'm not that familiar with rust so rustc/cargo differences confused me.

This seems like basic functionality that would be useful in cargo, couldn't it be added there?
comment
created
chicoxyzzy
username_0
I'm not sure, but looks like it's not possible because cargo tries to build the whole project and uses rustc's `--out-dir` flag under the hood so when I add `-o` flag there is a conflict and both flags are ignored. That's what warnings from my original comment say if I get it rigth
comment
created
dreifachstein
username_2
It is necessary if you don't want to use the EMCONFIGURE_JS hack. For example ffmpeg is cross-compile aware and is perfectly fine with a patched emcc.py with explicit output type control. And I think the code will end up more readable if done properly (pre-compute output and intermediate filenames before task execution).
If you are not against it I can contribute.
comment
created
kripken
username_1
Yeah, good points. Sounds ok to me. The one question I have is what to do with ambiguity, like `emcc input.cpp --output-format js -o output.html`?
comment
created
jgravelle-google
username_3
In that case I think we should ignore inferring the content of the file from the `-o` parameter, because the user has explicitly expressed their intent of what they want done.
comment
created
kripken
username_1
Well, the user has expressed two contradictory intents ;) Perhaps we should show an error in that case?
comment
created
jgravelle-google
username_3
It's not contradictory intent so much as a nonsense filename, which is a much weaker signal than `--explicitly-format-this-as html`. Filenames are just hints. If we have users who need a `.foo` extension but formatted as `.html` inside, why *not*?
comment
created
kripken
username_1
The issue is that, for better or for worse, filenames have not just been hints in emcc - when asked `-o a.html` we did emit an html, etc.

At minimum we should emit a warning, but I lean to an error myself.
comment
created
dschuff
username_4
I agree with both of you. IMO flags should be used instead of extensions to specify output type. But since they aren't in emscripten, an error is probably best.
comment
created
jgravelle-google
username_3
Is the issue that this would change behavior for existing users? Why would they start adding the explicit output preference *and* be relying on the existing behavior?

Or is it that having two ways to specify output would cause confusion as to which was preferred? I think by having one of the two take priority, users can expect it to work consistently.

At a high level, my concern is that we'd be adding code, and by extension rules for users, in order to *limit* flexibility, and I'm not sure what the benefit there is.
comment
created
dschuff
username_4
Oh, sorry I just reread the thread. If we are going to add a new flag, it should override the filename-selection because the whole point of having the flag right now is to use in situations where using the filename as a selector is inconvenient or impossible. Most likely this will mean that the output extension is something generic like no extension at all, or `exe` or `.o` or something, which means there will be no contradiction, so no problem. It would be weird if there were a contradiction like html vs JS, but I think the command line should still override any kind of implicit selection. So a warning makes sense there.
comment
created
kripken
username_1
Ok, sounds like mostly we are leaning towards a warning here. Before deciding, though, let's see what @username_6 thinks when he's back from vacation.
comment
created
GameKyuubi
username_5
Was this ever resolved?  I'd much rather use Cargo than raw rustc.
comment
created
juj
username_6
I would be ok with adding something like `--output-type <html|js|bc>`, with

```
emcc foo.c --output-type html -o out // Generates file 'out' that is a html file, and the other files such as `out.js` as usual
emcc foo.c --output-type js -o out // Generates file 'out' that is a JS file
emcc foo.c --output-type js -o out.html // Generates file 'out.html' that is a JS file
emcc foo.c --output-type bc -o out // Stops at bitcode generation time and creates 'out' which is a LLVM bitcode .bc file
```

I don't think any warnings would need to be emitted if one uses confusing/contradicting suffixes, because existing behavior without the `--output-type` directive would not be altered, so this flag could be treated as an override that takes precedence, and if one explicitly states an override, that is what they would expect to get. Perhaps the flag could be named as `--override-build-type` or `--force-build-type` or something like that to be explicit?
comment