[REQUEST] Possibility of naming each build ?

[aaulia]

Is it possible to name each build (--next) ? For example debug/release.

[clemos]

It's currently not possible But it might indeed be interresting to name builds using comments + a convention, like :

# name : debug

or something.

[frabbit]

yes i also thought about adding it by convention. I also thought about adding an own build description format like haxebuild or whatever where you can specify different hxml-files or commands for run/build/display. It should be easy to implement in the refacoring branch. what do you think. However adding a new build type doesn't mean that we can't add such conventions to simple hxml builds.

[clemos]

I don't really like adding yet another "project file" type on top of .hxml and .sublime-project. I actually think it would be even better if the refactoring branch could work without a real ST project (just open directory and run), but that's a different topic ;)

Maybe it could be interresting to do it using -D, something like -D build_release or something... (I don't know which characters are allowed there) Benefits :

• names can be easily extracted
• we don't need to parse comment lines
• the flag can be used in conditionnal compilation as well
• it can be easily adapted to NME/openFL which has similar flags

What do you think ?

[aaulia]

I still think the comment with convention is still the way to go. It doesn't touch the original hxml (I'm only talking about hxml here since in nmml the build is already named with HTML5/Android/etc).

Of course you can, for example, read if a build have "-debug" enabled, and add "Debug" or whatever to the entry. But I don't think it would be flexible enough.

What I had in mind is that I have an entry that only build the project, and entry that build and run (since I need to specify target with "-cmd"), and maybe build with/without preloader, and many other combination. So I think the bundle trying to be "smart" and comprehend the hxml is not the way to go for this (to much effort that could be spend elsewhere).

Just my 2 cent :)

[clemos]

I wasn't talking about "guessing" a name from flags like -debug or such. My suggestion was about using -D build_release rather than # build : release. For the reasons I explained above, I find it makes a lot more sense. Then it's just about choosing the appropriate prefix, maybe st_build_release to make sure we don't interfere.

[frabbit]

I don't like the idea to extract the build name from a compiler define. It doesn't allow meaningful names with spaces and special chars like "MyProject - Release" and it's mixing hxml logic with sublime text logic. I would prefer having a quick solution based on comments (which is not really hard to parse). Something like #buildName=MyProject - Release. In conjunction i would still love to define different run/build configurations for one selected build, this could be a separate file type or can also be integrated in the project file, something like this:

"settings" : { "builds": [ { "name" : "MyProject - Release", "build" : { "type":"hxml", file:"myProject.hxml", "haxe-args" : []}, "run" : ["nodejs", "bin/myBuild.js"] }, { "name" : "MyProject - Debug", "build" : { "type":"hxml", file:"myProject.hxml", "haxe-args" : ["-debug"]}, "run" : ["nodejs", "bin/myBuild.js"] } ] }

there should also be an option (false by default) which hides builds which are not defined in the project settings (if at least one exists).

If you don't specify a run a default run is chosen (e.g. nme run myFile.nmml in case of nme).

Of course the exact format to define these builds should be flexible and should work for hxml, nme, openfl and also for custom builds (just a cmd).

We can also integrate pre and post build commands in this format without much hassle.

what do you think?

[frabbit]

i added the naming by convention feature in the named_hxmls branch. i chose the following convention #build-name=Whatever

we could also choose name or st-build-name or st-name. I check exactly for "#build-name=", spaces are currently not allowed.

what do you think?

[clemos]

I'm really not comfortable with adding yet another project file. What I wouldn't want is a situation similar to .hxproj files : I don't like the way some projects more or less need FD to be built. I actually don't like anything that links too much any project to any IDE/editor. I'm also afraid the bundle becomes less and less simple to use...

As for comments vs defines, I'm fine with it.

[frabbit]

#build-name=My Project Name

is added in the refactoring branch.

[frabbit]

yes i understand what you mean, but that's why we also allow hxml, nme, openfl project files. If there is a real advantage to add such configuration in the sublime project file for example, i would introduce it as an alternative not a replacement. I think the plugin should be usable without or minimal configuration in small projects, but it should be flexible if you want to use it with larger/modular projects with more complex build and run requirements.

Why do you think it is less simple to use if we introduce something like this as an alternative?

[frabbit]

I actually think it would be even better if the refactoring branch could work without a real ST project (just open directory and run), but that's a different topic ;)

And yes, this should also work, seems like a regression (didn't try it without a project file in the last couple of weeks).

[frabbit]

I actually think it would be even better if the refactoring branch could work without a real ST project (just open directory and run), but that's a different topic ;)

that should be working again ;)