Providing target option for emcc

[chicoxyzzy]

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.

$ 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 cross-rs/cross#36 (comment)

[kripken]

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?

[chicoxyzzy]

I think this is the issue you mentioned.

However there is still no way to do it using cargo. It's only possible using rustc

[kripken]

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?

[chicoxyzzy]

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

[dreifachstein]

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.

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.

[kripken]

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?

[jgravelle-google]

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.

[kripken]

Well, the user has expressed two contradictory intents ;) Perhaps we should show an error in that case?

[jgravelle-google]

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?

[kripken]

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.

[dschuff]

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.

[jgravelle-google]

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.

[dschuff]

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.

[kripken]

Ok, sounds like mostly we are leaning towards a warning here. Before deciding, though, let's see what @juj thinks when he's back from vacation.

[GameKyuubi]

@kripken Was this ever resolved? I'd much rather use Cargo than raw rustc.

[juj]

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?

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.