Merging tool behavior? about hxcpp HOT 5 CLOSED

These all sound like good things.
I am happy to split the hx files into separate class files (thanks for
keeping my syntax).
As for colored syntax - not sure how you have done it, but I would like the
see something like:
Log.println("Error :dsfsjdlfjasdlf some issue");
or maybe:
Log.error("some issue"). which adds "Error" in red, and the rest in normal.
Or maybe:
Log.println("Error: The file ABC.hx could not be
found"). Or something that is easier to parse directly than xml, although I
think we could use regex to do this, rather than a proper parser - but
either way may be good.
This way we can turn the coloring off, if for example something is parsing
the output (IDE style). But I do like the colouring - on by default. Is
this what you had in mind?

I have added one class, hxcpp/Builder, which can be used to run the hxcpp
build tool on multiple targets. We could put the common classes somewhere
near there if you want to actually share the same physical code with other
projects (eg hxcpp/tool/PathManager). On one hand this should maybe not
belong as a lib in cpp, but on the other hand if it is already there, then
it could be used. I am leaning to just keeping the code in the tools/run
area. What do you think about this?

Can the refactor be done without introducing regressions? Is it mainly
just moving code around, add error checks and tweaking paths, or are you
looking to change the way variables are interpreted.
Hugh

On Sun, Mar 23, 2014 at 6:57 AM, Joshua Granick [email protected]:

I am comparing hxlibc and hxcpp, to see if the improvements from hxlibc
can be merged into hxcpp.

In hxlibc, the tools were refactored into separate class files, and the
common functions such as running a process or making a directory were made
to share the helpers from lime-tools. From a maintenance perspective, this
helps the hxlibc tools be more resilient, while also allowing us to make
fixes in one place. For an official Haxe dependency library, this obviously
does not make sense.

Unless there is an objection, I would like to help bring the improvements
into HXCPP, but in the process, I would like to ask if it is alright to
separate the run tool into multiple classes, and if these common functions
can be expanded. Being your project, I can respect if there's a specific
code format style you would prefer, etc.

For example, if you try to run a command on an exe that has a space in it,
the current HXCPP run tool will split the exe on the space, using the first
result as the executable, and the others as the beginning of the argument
array.

In hxlibc, it checks for an escaped space, such as "\ ", and ignores this.
It then escapes spaces it finds, based on the platform (you might be
calling "my tool.exe") and it also expands ~/ to $HOME if encountered.

When creating a directory in the HXCPP tool, it splits the directory by
the "/" character, and I believe it may also be picky about trailing
slashes.

In hxlibc, it converts backslashes "" to forward slashes "/", it splits
the path but it is also sensitive to absolute paths, trailing slashes and
some other considerations.

The hxlibc tool also allows for -verbose output, I believe, and can
colorize when supported by the target, for example, "Error: " in red and
the message in white. The error messages have also been cleaned to try to
be more helpful, and attention has been paid to throw stack traces only
when an error is truly within the tools. If you have an error calling "g++"
the error lies there, not within the tool, so sharing a stack trace is more
confusing/messy than helpful.

Interested in your feelings on this, thanks!

Reply to this email directly or view it on GitHubhttps://github.com//issues/36
.

from hxcpp.

Hi
Your nme tooling issues do look like a recursive "include.xml" include
issue. Do you have an include.xml in your nme directory? You should not.
However, the tool needs to guard against this too.

Hugh

On Sun, Mar 23, 2014 at 9:19 AM, Hugh Sanderson [email protected] wrote:

These all sound like good things.
I am happy to split the hx files into separate class files (thanks for
keeping my syntax).
As for colored syntax - not sure how you have done it, but I would like
the see something like:
Log.println("Error :dsfsjdlfjasdlf some issue");
or maybe:
Log.error("some issue"). which adds "Error" in red, and the rest in
normal. Or maybe:
Log.println("Error: The file ABC.hx could not be
found"). Or something that is easier to parse directly than xml, although I
think we could use regex to do this, rather than a proper parser - but
either way may be good.
This way we can turn the coloring off, if for example something is parsing
the output (IDE style). But I do like the colouring - on by default. Is
this what you had in mind?

I have added one class, hxcpp/Builder, which can be used to run the hxcpp
build tool on multiple targets. We could put the common classes somewhere
near there if you want to actually share the same physical code with other
projects (eg hxcpp/tool/PathManager). On one hand this should maybe not
belong as a lib in cpp, but on the other hand if it is already there, then
it could be used. I am leaning to just keeping the code in the tools/run
area. What do you think about this?

Can the refactor be done without introducing regressions? Is it mainly
just moving code around, add error checks and tweaking paths, or are you
looking to change the way variables are interpreted.
Hugh

On Sun, Mar 23, 2014 at 6:57 AM, Joshua Granick [email protected]:

I am comparing hxlibc and hxcpp, to see if the improvements from hxlibc
can be merged into hxcpp.

In hxlibc, the tools were refactored into separate class files, and the
common functions such as running a process or making a directory were made
to share the helpers from lime-tools. From a maintenance perspective, this
helps the hxlibc tools be more resilient, while also allowing us to make
fixes in one place. For an official Haxe dependency library, this obviously
does not make sense.

Unless there is an objection, I would like to help bring the improvements
into HXCPP, but in the process, I would like to ask if it is alright to
separate the run tool into multiple classes, and if these common functions
can be expanded. Being your project, I can respect if there's a specific
code format style you would prefer, etc.

For example, if you try to run a command on an exe that has a space in
it, the current HXCPP run tool will split the exe on the space, using the
first result as the executable, and the others as the beginning of the
argument array.

In hxlibc, it checks for an escaped space, such as "\ ", and ignores
this. It then escapes spaces it finds, based on the platform (you might be
calling "my tool.exe") and it also expands ~/ to $HOME if encountered.

When creating a directory in the HXCPP tool, it splits the directory by
the "/" character, and I believe it may also be picky about trailing
slashes.

In hxlibc, it converts backslashes "" to forward slashes "/", it splits
the path but it is also sensitive to absolute paths, trailing slashes and
some other considerations.

The hxlibc tool also allows for -verbose output, I believe, and can
colorize when supported by the target, for example, "Error: " in red and
the message in white. The error messages have also been cleaned to try to
be more helpful, and attention has been paid to throw stack traces only
when an error is truly within the tools. If you have an error calling "g++"
the error lies there, not within the tool, so sharing a stack trace is more
confusing/messy than helpful.

Interested in your feelings on this, thanks!

Reply to this email directly or view it on GitHubhttps://github.com//issues/36
.

from hxcpp.

Yes, that's it! I suppose I created an include.xml for NME when I was trying to see if lime-tools could build it. Removing it does fix most of the samples. It would be ideal to be able to support one because the lime-tools use this to know what libraries, templates and other files to include. For example: https://github.com/openfl/lime/blob/master/include.xml

from hxcpp.

I'll take a look and see about making some of these changes. I'll preserve the current class names (you can refactor later if it makes sense), preserve the code format, but also expand some of the functions to include the extra behavior. I will try to be especially sensitive about something that could cause a regression or change behavior. The intention, of course, is to make things more solid.

The way we handle color is by allowing ASCII codes directly in the output. This allows the flexibility of defining background or foreground color, bold, italic, and other styles (though not all shells support all features). If the shell says it does not support color, or it is Windows and ansicon is not detected (Windows prompts don't really support word-by-word color otherwise), then we use a regex to strip the color codes. So far, this appears to be compatible with IDEs and each shell tested.

from hxcpp.

I'll mark this as closed, improvements have been long merged :)

from hxcpp.