[Discussion] List used defines in haxelib.json (optional)

[boozook]

I propose to discuss the possibility of introducing a new optional field "defines" into the haxelib.json. Only as information for men, tools, utilities, IDEs, etc..

I mean list of used build-in defines and custom defines like -D foo (all in one list).

e.g.:

{
  "name": "hxcpp",

  "defines": [
    {
      "name":"HXCPP_M32",
      "type":"bool",
      "description":"Sets target arc to Mac OS X 32 bit"
    },
    {
      "name":"IPHONE_VER",
      "type":"string",
      "description":"Sets the version of target iOS via passing parameter to 'xcrun --sdk iphoneosX.X'. e.g.: `-D IPHONE_VER 9.1`."
    }
  ],

  "url": "http://gamehaxe.com/",
  "license": "BSD",
}

For what?

1. It may help to standardize documentation of definitions;
2. Can impl./arrange autocompletion of defines at the IDE level;

---

P.s.: Also will be cool same list for custom metas @custom/@:custom/`@:meta(foo, bar) with note about its args.

[ibilon]

A standardized layout to have these sure, but why in haxelib.json, haxelib doesn't use this.

[boozook]

Okay, maybe another one parsable file in root of library. Anyway I propose to discuss and declare a format and in the future to describe it as a standard for Haxlibs packages.

[nadako]

I think the "haxelib doesn't use this" argument is not very valid, since e.g. it also doesn't use releasenote. It's used by the repository server to add it to the db, so the website could display it, but we're talking about the haxelib tool.

The point is, it's a useful information about the library that can be parsed by ides and doc generators, so I think it'll fit well in haxelib.json. Actually, even the haxelib tool can be taught to display a helpful information abot library-specific defines/metadatas and whatnot.

In my vision, haxelib.json very similar to NPM's package.json and I think we should look also into borrowing some features from it.

That said, I don't want to implement it right now (since we want to seriously cleanup/refactor haxelib first), but the idea itself seems nice, but we'll have to give it more thought to design this properly.

[boozook]

don't want to implement it right now...

I'm sure, that no implementation is needed now. Currently all new extra-fields in haxelib.json are ignoring and don't beaks the tool (code).

I think as a first step we need to get consensus/agreement about needing, placement and format of data. Next - to describe it as a page in manual. In the future and after refactoring the next step - validation of new data. That's all.

[nadako]

IMO, design issues often surface when we implement the feature, so I'm strongly against documenting it in manual before implementation. You're free to work on design tho :-)

[ibilon]

Make a quick comparison of npm/gem/cargo/haxelib package file https://docs.google.com/spreadsheets/d/1c6vGi6D8HCwTpzm7eX9cSAD8-GovZnUqWksBFMOGqeQ/edit?usp=sharing

It's more that probable that I missed stuff and put "no" where there is support ;)