Target configuration from command line

[Simn]

The idea is to add a command line flag which allows specifying a custom target name, e.g. -custom xyz. This then does the following:

1. Set our internal target value to Custom("xyz"). This causes the standard library identifier to be xyz, so users can implement their own things there.
2. Look for a xyz.json (or some other convention) in the class path. This file contains a convention for the target configuration, such as { "static": true, padNull: false }.

[ibilon]

I had a similar idea :) The difference is I thought of something like -custom SomeClass or -custom path/SomeClass.hx with all the configuration in the class, read with eval maybe? Detail though.

[Simn]

The problem is that want to set the target value really early, and booting up the macro engine might cause something in the target context before the macro is executed. That's why I want to just have a dumb command line configuration and then take it from there.

[ncannasse]

I would go with something more advanced/explicit, such as --custom-target xyz

On Sat, Sep 16, 2017 at 11:19 PM, Simon Krajewski notifications@github.com wrote:

The problem is that want to set the target value really early, and booting up the macro engine might cause something in the target context before the macro is executed. That's why I want to just have a dumb command line configuration and then take it from there.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/haxe/issues/6582#issuecomment-329995520, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-bwJSgyBd6_Dt0q5vmVhgbymW23ig_ks5sjDtfgaJpZM4PZusk .

[Simn]

How about -target?

That reminds me we still have to specify the output file/path somehow.

[ncannasse]

Given that it's mostly for experimental things, I insist of having a long name + starting with two dashes :)

On Mon, Sep 18, 2017 at 5:28 PM, Simon Krajewski notifications@github.com wrote:

How about -target?

That reminds me we still have to specify the output file/path somehow.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/haxe/issues/6582#issuecomment-330260127, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-bwF2NxKBKuGDX7jyAmG4FwJI6qf0Yks5sjowmgaJpZM4PZusk .

[ibilon]

The number of dashes should really be coherent on all arguments.

[Simn]

Given that it's mostly for experimental things, I insist of having a long name + starting with two dashes :)

Could you start drinking some beer again so you're making more sense? :)

[Aurel300]

How does this affect the generator used? E.g. if I do

-js out.js
-target xyz

It still uses the js generator but … Uses a different std namespace?

[Simn]

That should probably fail with "multiple targets".

[Aurel300]

Correct me if I'm wrong, but having a JSON which says whether a target is static or not + std library implementation is not the same as specifying a custom generator.

By the way, being able to specify a custom generator would be amazing and it should be in Haxe 😢

[Simn]

You can implement whatever funky generator you want using onGenerate. The only problem with that was that you couldn't configure the target and had to somehow re-use an existing stdlib.

[fullofcaffeine]

When you're talking about onGenerate, you're essentially talking about the CustomJSGen, right? Shouldn't we rename that to more general btw, since any generator for any language can be implemented using it?

Also, as a side question, is it already possible to create custom generators in OCaml and load them as plugins?

On Thu, Sep 21, 2017 at 8:14 AM, Simon Krajewski notifications@github.com wrote:

You can implement whatever funky generator you want using onGenerate. The only problem with that was that you couldn't configure the target and had to somehow re-use an existing stdlib.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/haxe/issues/6582#issuecomment-331152511, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE9YFnmoSdvlUrTohepVDLW0bha26OTks5skmElgaJpZM4PZusk .

[Simn]

When I'm talking about onGenerate, I'm talking about onGenerate.

And yeah you can probably build an OCaml generator using eval.vm.Context.loadPlugin (which as I've just noticed doesn't show up on api.haxe.org for some reason). That feature is pretty experimental though and probably requires some bugfixes.

[Simn]

I just tried it because I was curious. Here's what I did:

1. Place this file in haxe/jsgen.ml:

open EvalValue
open EvalEncode
open EvalContext
open MacroApi

let generate () =
    let com = (get_ctx()).curapi.get_com() in
    Genjs.generate com;
    vnull
;;
EvalStdLib.StdContext.register ["generate",vfun0 generate]

2. Generate plugin: make PLUGIN=jsgen plugin

3. Copy jsgen.cmxs to Haxe project.

4. Use this Main.hx file:

class Main {
    static public function main() {
        register();
    }

    macro static function register() {
        var plugin = eval.vm.Context.loadPlugin("jsgen.cmxs");
        haxe.macro.Context.onGenerate(_ -> plugin.generate());
        return macro null;
    }
}

5. Compile it with haxe -cp src -main Main -js test.js --no-output

That gave me a test.js file as expected. The --no-output is just there so the real generator isn't run.

[back2dos]

7576 reminded me of this. Will this require any breaking changes?

My suggestion would be to make the target configuration purely via command line arguments. In the end a custom target can be shipped as a lib that sets all the compiler flags it needs (in extraParams.hxml) and you can just go haxe -lib hxdart -main Main -D output=yay.dart

[Simn]

Some thoughts:

• We want to allow partial configuration, which makes some sort of inheritance mechanism a requirement.
• A straightforward approach is to allow --target some/config.json. This requires some additional work on the side of haxelib if it is to be used from extraParams.hxml because we want to be able to resolve to a config within the library.
• The actual config should consist of the pf_ values and a target name (for #if purposes and such).
• An open question is if we need --output to pass an output value to the generator. This could already be done via a custom -D flag, but a standardized way might be nicer.

[Simn]

This was closed in #11128.