Default compiler setting
Locked
 
|
René and interested parties --
A recent question on the list suggested a new idea to consider. Currently passing the nrx.compiler parameter forces NetRexxC to use a specific Java compiler - either javac or ecj. My suggestion is to modify that behavior so that the nrx.compiler parameter or it's default value is a starting place only and NetRexxC actually looks for both compilers. In other words, if the first compiler (javac or ecj) cannot be found, try to find the other one and use it. In the case of using module NetRexxF.jar, the default compiler to look for should be ecj since it is included in that module. This change would eliminate compile failures due to forgetting or not knowing about the nrx.compiler setting and would make it more likely that NetRexxC will be successful rather than failing due to Java compiler not found. The only drawback I see to this change is that it might not be totally clear which compiler was actually used but that can be ameliorated by new output messages which draw attention to the alternate compiler selected. Does anyone see problems with this approach? -- Kermit _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Like the idea of stating the Java compiler name and version up with the
Netrexx version, at least under high enough levels of verboseX. My vote would be for it to show at least verbose3, the default. Jeff On 5/26/2014 1:47 PM, Kermit Kiser wrote: > René and interested parties -- > > A recent question on the list suggested a new idea to consider. > Currently passing the nrx.compiler parameter forces NetRexxC to use a > specific Java compiler - either javac or ecj. My suggestion is to > modify that behavior so that the nrx.compiler parameter or it's > default value is a starting place only and NetRexxC actually looks for > both compilers. In other words, if the first compiler (javac or ecj) > cannot be found, try to find the other one and use it. In the case of > using module NetRexxF.jar, the default compiler to look for should be > ecj since it is included in that module. > > This change would eliminate compile failures due to forgetting or not > knowing about the nrx.compiler setting and would make it more likely > that NetRexxC will be successful rather than failing due to Java > compiler not found. > > The only drawback I see to this change is that it might not be totally > clear which compiler was actually used but that can be ameliorated by > new output messages which draw attention to the alternate compiler > selected. > > Does anyone see problems with this approach? > > -- Kermit > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
On 26-May-14 12:47, Kermit Kiser wrote: Does anyone see problems with this approach? Not only do I not see any problems, I do see an elegant — and element of least surprise — solution to an often confusing situation. A simple, “Compiling
with I like it a lot.
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
Kermit,
I think that is a good idea, but the implementation must be so that it does not introduce more problems than it solves. It should stay a fallback option, and should state clearly when it deviates from an explicitly specified one. By the way, the -time option already specifies which compiler was chosen. best regards, René. On 26 mei 2014, at 13:47, Kermit Kiser <[hidden email]> wrote: > René and interested parties -- > > A recent question on the list suggested a new idea to consider. Currently passing the nrx.compiler parameter forces NetRexxC to use a specific Java compiler - either javac or ecj. My suggestion is to modify that behavior so that the nrx.compiler parameter or it's default value is a starting place only and NetRexxC actually looks for both compilers. In other words, if the first compiler (javac or ecj) cannot be found, try to find the other one and use it. In the case of using module NetRexxF.jar, the default compiler to look for should be ecj since it is included in that module. > > This change would eliminate compile failures due to forgetting or not knowing about the nrx.compiler setting and would make it more likely that NetRexxC will be successful rather than failing due to Java compiler not found. > > The only drawback I see to this change is that it might not be totally clear which compiler was actually used but that can be ameliorated by new output messages which draw attention to the alternate compiler selected. > > Does anyone see problems with this approach? > > -- Kermit > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Kermit Kiser
Hi Kermit,
thank You *so much* for following that up! :-) *maybe* we shoould even *add option -time* as a default to the batch (.bat / .cmd / .sh) jobs delivered, so that NewBe NetRexx user does always know - which compiler is used - and how quick it is When the group should reject that idea, I shall of course simply add option -time in any and all variants I personally am using ;-) Kind regards from Vienna, part Austria ... and: EU election has been completed meantime ! Thomas Schneider ==================================================================== Am 26.05.2014 19:47, schrieb Kermit Kiser: > René and interested parties -- > > A recent question on the list suggested a new idea to consider. > Currently passing the nrx.compiler parameter forces NetRexxC to use a > specific Java compiler - either javac or ecj. My suggestion is to > modify that behavior so that the nrx.compiler parameter or it's > default value is a starting place only and NetRexxC actually looks for > both compilers. In other words, if the first compiler (javac or ecj) > cannot be found, try to find the other one and use it. In the case of > using module NetRexxF.jar, the default compiler to look for should be > ecj since it is included in that module. > > This change would eliminate compile failures due to forgetting or not > knowing about the nrx.compiler setting and would make it more likely > that NetRexxC will be successful rather than failing due to Java > compiler not found. > > The only drawback I see to this change is that it might not be totally > clear which compiler was actually used but that can be ameliorated by > new output messages which draw attention to the alternate compiler > selected. > > Does anyone see problems with this approach? > > -- Kermit > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by rvjansen
I would suggest to make the -time option the default in release 3.03 final.
Always useful to see how quickly NetRexx does solve the task in question ;-) Thomas. ============================================================== Am 27.05.2014 00:09, schrieb René Jansen: > Kermit, > > I think that is a good idea, but the implementation must be so that it does not introduce more problems than it solves. It should stay a fallback option, and should state clearly when it deviates from an explicitly specified one. > > By the way, the -time option already specifies which compiler was chosen. > > best regards, > > René. > > On 26 mei 2014, at 13:47, Kermit Kiser <[hidden email]> wrote: > >> René and interested parties -- >> >> A recent question on the list suggested a new idea to consider. Currently passing the nrx.compiler parameter forces NetRexxC to use a specific Java compiler - either javac or ecj. My suggestion is to modify that behavior so that the nrx.compiler parameter or it's default value is a starting place only and NetRexxC actually looks for both compilers. In other words, if the first compiler (javac or ecj) cannot be found, try to find the other one and use it. In the case of using module NetRexxF.jar, the default compiler to look for should be ecj since it is included in that module. >> >> This change would eliminate compile failures due to forgetting or not knowing about the nrx.compiler setting and would make it more likely that NetRexxC will be successful rather than failing due to Java compiler not found. >> >> The only drawback I see to this change is that it might not be totally clear which compiler was actually used but that can be ameliorated by new output messages which draw attention to the alternate compiler selected. >> >> Does anyone see problems with this approach? >> >> -- Kermit >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |