On 2015-12-04 12:50, Magnus Ihse Bursie wrote:
Comments inline.
I see. I'm fine with this. Just one note, if you had
jab_url=$jab_server/$data_string, maybe this should be more obvious.
And it's a nice bit of DRY.
Sure, seems reasonable.
144 * // For certain dependencies where a legacy distribution mechanism is
145 * // already i place, the "javare" server layout is also supported
"in place". Also, missing period.
150 * // buildnumber (optional), files and checksumfile is possible for
"build number", "checksum file"
* // aritfacts following the standard layout.
"artifacts"
* // For other files, use checksumpath and paths instead
"checksum path"
62 * input.build_unix_os
63 * input.build_unix_cpu
66 * input.build_unix_platform
What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
Clarified
I still think this is not so good. What does build_unix_os contain? "Windows" or
"Cygwin"? Is it used only on Windows? And why "unix"? Is the whole reason for this to be
able to separate 32 and 64 bit cygwin?
Yes, and it would apply the same if we were to use msys. On a 64bit
windows, you can run either a 32bit or 64bit unix emulation layer. I
thought unix_emulation_layer was a bit long so shortened it to unix. I
agree the name is not good.
In the build system, we have a notion of "os env", which is the same as "os" in most cases, but
isn"cygwin" or "msys" on Windows. Maybe we should use the same terminology here, if we describe the
same thing.
os_env only describes msys or cygwin, not the bitness. I need both to be
able to pick the correct executables.
/Erik
Except for the things I noted, your fixes look good.
/Magnus
