search

HaxeFoundation / haxe-evolution

Repository for maintaining proposal for changes to the Haxe programming language
111 stars 58 forks source link

platform '--switch' within hxml, labeled '--next' passed with hxml call. #42

Closed nanjizal closed 6 years ago

nanjizal commented 6 years ago

When building hxml I will ask my mac to open a browser.

But when creating libraries that others may try using, I want to support atleast windows,mac and linux from simple hxml build scripts, while where possible avoiding xml non generic solutions or complexity of special library run scripts.

--next
-cmd echo '<!DOCTYPE html><meta charset="UTF-8"><html><body><script src="test.js"></script></body></html>' >../binWebGL/index.html
-cmd open ../binWebGL/index.html

the simplest solution is a secondary file?

--next
--switch win: win.hxml mac: mac.hxml linux linux.hxml

It seems minimum that haxelib should support something like --if or --switch for all currently widely used platforms, but ideally atleast just windows, mac and linux so that we can provide scripts to automatically open the browser at the very least. I am sure that I have brought this up before, and I know that any suggestions that were made to me last time did not end up being simple and practical to use on projects. It's a requirement that I have had for many years, and something that I understand is not a priority but would like it added to evolution, but would be happy with alternative hxml only solutions.

Suggestion it would be very useful to pass in a parameters 

haxe compile.hxml next heapsWebGL
--next heapsWebGL
# only called if the next is in the terminal call
--next

So that any --next statement that has a parameter is only run if it is called when running the hxml, this makes it much easier to use a single hxml file without clutter of one for every target or a separate build folder that then create folder level complications and user confusion.

bendmorris commented 6 years ago

Edit: I'll move this to a separate issue to stay on topic. TL;DR I think we should solve this problem, but shouldn't overload the hxml format so much.

nanjizal commented 6 years ago

What I requested was a minor change to allow more practical use, they are rebuilding haxelib2 but that may take a long time. I can try to add the changes to current haxelib perhaps but it would need a go ahead on a concept before trying. The problem is if you look at 'Quick' is that every toolkit uses a different system and nme one is pretty similar but for some reason slightly different so you can't assume one is better than the other? I can work with the toolkits all being different but for just working with simple js stuff it's annoying that I can't call open the browser the same way on all platforms. That is the part that is annoying because then your library will look broken when a windows user downloads it.

nanjizal commented 6 years ago

I can look to make a minor change to haxelib if a simple idea is agreed but would not attempt a total change like your suggestion.

RealyUniqueName commented 6 years ago

I usually go with -cmd haxe -main Run.hx --interp and do whatever I need depending on any circumstances.

Simn commented 6 years ago

hxml is fundamentally unsuited for something like this, so we'll need a different solution here.