From: "Johannes Schindelin" <johannes.schinde...@gmx.de>
Hi Philip,
On Thu, 20 Nov 2014, Philip Oakley wrote:
Are the patches going in the right direction?
Yes.
Magic. Glad of the confirmation
A couple of general comments:
- please do not comment out code. Just remove it.
It's my debugging style until I get it working ;-0
- the first three commit messages look funny, being indented by 4
spaces... unintentional?
I think that was from one of the tools I was using at the time. They'll
be tidied and reflowed for the final version(s).
Is the processing of the .obj file in engine.pl sensible?
Yes, but instead of adding dead code, it would be better to use the
comment "# ignore". I would also strongly suggest to hard-code the
complete file name instead of just the extension.
True, I realised that after posting (isnt it always the way).
We know exactly which
file name we want to ignore, and if there should be another .obj file
eventually, it would be wrong to ignore it, too.
My concern was more about why a 'make' would produce .obj files (rather
than .o files) in the first place. As I understand it we should never
see .obj files generated from make with the exception of these ones that
are library files implicitly known to MSVC - any thoughts?
and the extra care with s/\.o$/.c/ avoiding s/obj/cbj/.
Technically, you need to use a group \($\|[ \t]\), but I think that
that
would be overkill.
Does it affect the Qmake capability? (I've no idea)
Frankly, neither do I ;-) But since you touched only engine.pl, I
would
expect Qmake not to be affected at all, right?
As I understood the call sequence merry go round, the engine can pull in
either function depending on command line options, hence the open
question. But like you say, why expect it to be affected, and no-one has
mentioned on list for years;-)
Is the quoting of filenames correct? (my perl foo is cargo cult!)
IANAPME (I am not a Perl Monk either), but it looks good to me.
OK.
I've also updated the vcbuild/README to mention Msysgit (which
will be replaced soon by the newer/better Git-for-windows/SDK
(https://github.com/git-for-windows/sdk), but the benefits still
apply.
The path you used is /msysgit/bin/msvc-build, but the real path would
be
/bin/msvc-build.
Obviously, the patches will need squashing together,
To the contrary, I like the current separation of concerns.
At the moment the first patch doesn't fully cure the .sln build, but
there's no test anyway so bisecting would be problematic.
I'm happy to keep them small separate and clean ;-)
Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
