William A. Hoffman wrote:
At 10:40 PM 8/14/2006, Igor Peshansky wrote:
- The other option is to use mingw-make, and only use cygwin make
for cygwin linked programs only.
Incorrect. If you use Cygwin make, it's very easy to invoke Windows
programs by converting their arguments with "cygpath -w" (or, barring
that, with a perl or sed script). I've done that, others have done that.
If you are generating the code to invoke the Microsoft cl compiler, simply
use something like $(foreach f,$^,$(shell cygpath -w $f)) as the argument
to cl.
I have to say yuck!, and performance hit. So, for every path that gets
passed to the compiler you have to launch a process that does string allocation
and conversion. I do not think this is a realistic solution for larger
projects. I would not want CMake to generate makefiles with cygpath -w
being invoked multiple times per compiler run. So, I will restate that
there is no workable solution to use cl with cygwin make anymore.
As one of those "others", I have to point out that it WJFFM. As for
"larger projects", I just had to make a source tarball, so I have a nice
statistic: *gzip'd*, it's about 2.6 MB. I'd say that qualifies as
"large". I guess that makes me not "realistic"?
Is it slower? Yeah, but that's part of doing business. Some time I may
decide to optimize it by converting some of my wrapper scripts to C
code. I think the hit is from the "launch a process" step, not "string
allocation and conversion".
Also, you could translate paths to e.g. '$DRIVEC/some/where.c', and use
$(subst) to alternately replace '$DRIVEC' (which should be a unique
identifier, like '__this_is_drive_c', NOT '/cygdrive/c') with a POSIX or
DOS equivalent as appropriate.
--
Matthew
Only Joe suffers from schizophrenia. The rest of us enjoy it.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
