bsc seems to ignore -o output location for bs-specific artifacts

[chenglou]

Repro: bsc -c -o a src/hello.ml

This will generate a a.cmi in the current directory, and hello.cmj and hello.js in the src/ directory, contrary to the equivalent ocamlc command which generates a.cmi and a.cmo in the current dir.

[bobzhang]

Indeed, at least we should make sure cmj and cmi behaves in the same way.

May I ask about your use case? -o is used more in the linker, I would suggest not to use it in bucklescript right now, change hello.cmi to a.cmi will probably break your build system.

If you want to output js in a separate directory, we have a better option to do that: https://bloomberg.github.io/bucklescript/NPM-Support.html

checkout -js-npm-output-path

[chenglou]

The use-case is that we want the artifacts aggregated in a single directory that newcomers can backspace to delete, in case they screw up (just like for npm). More importantly, our workflow will likely use lots of symlinks through npm link, so if you have A and B both depending on C, we don't want A and B thrashing on C's directory by overriding the artifacts each time (they might be compiled with different flags, so we can't share them between A and B).

(I did try -js-npm-output-path but yeah, the cmj file needs to move too)

Renaming the artifacts are really important for us. It's for implementing namespaces (for compiling to native). a.ml -> myNameSpace__a.cmi. And then we do some module alias + opening tricks to make this all work (if you're ever interested: https://github.com/chenglou/jengaboot. Not well-commented enough though. Still polishing it)

[bobzhang]

I am interested in support of namespace, what would you expect the name of js files, since the name of js files also matters. Should it follow the -o ?

[chenglou]

Yes, just like ocamlc. We could probably defer to a js module bundler to solve namespaces, but our jengaboot's way of doing it solved namespacing for native compilation already so (again, for us) we might as well use the same code and spare the js bundlers some steps. Of course not everyone use our setup, so if BuckleScript wants to support namespaces itself, it's still valuable to others.

(Moving the artifact is really important too)

[bobzhang]

so for the first step, I would keep cmj behaving the same as cmi, get renamed and moved into another directory, and see how it works with your internal build system

[chenglou]

Thanks! It should just work.

[bobzhang]

@chenglou try npm install bs-platform again,

bgit>bsc -o xyxx -c tmp/xx.ml 
bgit>ls xyxx*
xyxx.annot  xyxx.cmi  xyxx.cmj

note I would expect there might be other issues

[chenglou]

Thanks! The JS file still generates alongside the source file but I can change that with -js-npm-output-path. The other thing is, there doesn't seem to be a cma equivalent in bsc (the -a flag in ocamlc) anymore (is it 2ba721d#diff-147a7f2b514d7ff083fd8ca870dbf33bL84?). We generate intermediate cma files for easier compilation, so that we don't have to include all the transitive files for compiling at the end. Will cma ever make sense for bucklescript?

[bobzhang]

removing -a is intentional, since it does not make sense in JS context currently, it might make sense in the future

We generate intermediate cma files for easier compilation, so that we don't have to include all the transitive files for compiling at the end.

Can you elaborate? so far as I know, cma only makes sense when linking.

-js-npm-output-path is aware of package.json, while -o is relative to current working directory, we can discuss more about the design

[chenglou]

Yeah, it's just an extremely convenient way to link ocamlc someFlags foo.cma bar.cma baz.cma blabla.cmo instead of including the whole list of cmos that constitute the foo/bar/baz cma, at final linking time. I'll work on removing this tonight and get all the cmos in order I guess? cc @jordwalke

[bobzhang]

I am a bit lost, bsc does not generate cmo files, it generates cmj(for optimization) and js files

[chenglou]

Sorry yeah, I was talking about our current native compilation. It would be cmjs instead in the case of BuckleScript.

[bobzhang]

@chenglou I am unclear about the context, let me know what I could help. If bsc accept namespace as a command line option of the compiler, maybe we can embed it in the compiler level

[bobzhang]

close this issue, feel free to reopen it when necessary

[bobzhang]

For the record, since -o, -c is per file based, this will have no effect on -bs-files or -bs-main