Standardized build config

[bendmorris]

Moved from https://github.com/HaxeFoundation/haxe-evolution/issues/42

I agree with the goal but we're bumping up against the limits of what a format like hxml should reasonably support (hierarchical structure?) There's a natural split between compiler args and build configuration: build config should be flexible and expressive, and generates a set of compiler args for a single build, which can be simple and specific. So an alternate approach would be to standardize what build configuration looks like across projects, rather than overloading hxml.

So my alternative suggestion is to standardize a subset of OpenFL's project.xml/include.xml functionality, because that project has already solved this problem in an elegant way. (Syntax and format are less important than functionality here, pick your favorite markup language. I'll use YAML for this example because it's concise.)

There has also been a suggestion to add more metadata fields to haxelib.json, and include.xml solves that problem as well. If haxelib.yaml (or whatever) is present, it takes precedence over haxelib.json, and otherwise can include the same information. And while we're at it this also eliminates the need for extraParams.hxml.

name: hxpk
version: "0.1.0"
license: "MIT"
contributors: ["bendmorris"]

src: ["src"]

flags:
- "-dce=full"

dependencies:
- format
- hxbit

section:
- if: test
  unless: no-test
  flags: ["-debug"]
  dependencies: ["unit"]
  src: ["src-tests"]

This generates a set of compiler args: haxe -cp src -dce=full -lib format -lib hxbit. If called with -Dtest, it adds extra args: -debug -lib unit -cp src-tests.

There might be pushback that "haxe/haxelib is not a build tool." True, but having so much fragmentation among build tools is not great and Haxe doesn't have a clear winner in that space. At minimum we should have a standard format and set of semantics that works for basic projects and is expressive/extensible enough for build tools to consume without needing to provide their own entirely separate format.

[markknol]

how would you run a configuration with specific section?

[bendmorris]

The if/unless refer to defines: haxe project.yaml -D test

[back2dos]

haxe/haxelib is not a build tool

As Alex pointed out, haxe is a formidable build tool already.

build config should be flexible and expressive

If we want it to be flexible and expressive, why use YAML (or other markup) rather than Haxe? You can still do haxe --run Build and then let your Build class read some YAML file if that makes you happy.

I think we should rather provide a library that hosts solutions for common problems that you have to solve when building (copying around files, opening stuff in the browser, etc.)

[nanjizal]

I have to agree the problem which I raised was mainly that you can't control which -cmd are run on a platform, which is common for say opening a browser but for any terminal command. I feel yaml is overkill and requires too much learning on users, hxml is a quick and simple tool for basic use, I am also unsure if 'common problems' is very flexible for a language as flexible as haxe. And even with a simple case you may want a specific browser etc.. too much to get right, -cmd is more flexible but the platform aspect is annoying. My revised proposal which is very simple is initially to support a variation on -cmd which would be completely backwards compatible.

-cmd
-cmdMac
-cmdLinux
-cmdWin

This may not be perfect, as you would need to perhaps repeat yourself on mac and linux, but it would cover many many use cases, I would imagine it would be quite a simple change, simple is good.

I think anything more while your working on new Haxelib solutions is probably not sensible, this is a change that would be nice to get into Haxe4, and potentially 3.4.8 iteration ?

The main problems are not large, I would prefer that a solution is not over-engineered but just good enough mostly.

[bendmorris]

If we want it to be flexible and expressive, why use YAML (or other markup) rather than Haxe?

It's declarative, it's more concise than Haxe and much faster to write. To reiterate, specific format/syntax isn't important, it's the set of functionality that I'm suggesting we add. Maybe hscript is something to consider.

You can still do haxe --run Build and then let your Build class read some YAML file if that makes you happy.

This, or "run an arbitrary command afterward and do whatever you want," is a solution in the vein of "you can do it with a macro" - technically true but not standardized or accessible. I can do anything I want now, but the normal user flow could still be improved. OpenFL is a common onramp for new Haxe developers and frankly the ease of getting started with OpenFL beats native Haxe by a long shot, part of which is a dead simple declarative project format.

I think we should rather provide a library that hosts solutions for common problems that you have to solve when building (copying around files, opening stuff in the browser, etc.)

This is sort of the reverse of what I'm suggesting. I think the declarative part - metadata, target definitions, command invocation - is the part that will be useful to share. The "how" will vary too much across projects to make a useful shared library, and that's the part where executing Haxe or an arbitrary command should come in.

[Gama11]

Maybe hscript is something to consider.

Why hscript rather than proper Haxe? With the former you won't get proper syntax highlighting, completion, etc..

[bendmorris]

Only that it's a little more concise. I do think a declarative markup format would be better. Configure in a declarative format, write your build logic in Haxe.

[kevinresol]

I only hope that we don't create another gradle or webpack

[kevinresol]

I think we still need a haxe library that does that actual build task. After all, any declarative format must be interpreted by either ocaml or haxe code. And I think haxe is obviously preferred.

For people who have different flavor, they can build their own plugins to read config files, may it be haxelib.yaml, openfl-format, flow-format, kha-format, etc, then convert these config into actual Build API calls provided by that library.

And for people who don't use the declarative way they can simply hook up the library and write their own logic in haxe.

Everyone is happy.