If you're build has a compile error, and then you fix it and then you
build again, it seems you get an infamous:
/cygdrive/c/Eclipse/workspaces/android-sdk/.test/Test/obj/local/armeabi/objs/test2//test.o.d:1:
*** target pattern contains no `%'. Stop.
Looking at test.o.d, I see Windows paths.
So I removed my objs directory and launched the build again (simply
doing a clean resulted in the same error). And low and behold, the .d
file contains cygwin paths. eh?
Is this considered a bug? I really, really want to support the
official NDK with the CDT, but fighting cygwin isn't in my plans, at
least not this much. I won't get into how much hassle it's been just
to get the CDT to call make appropriately.
Sorry for the rant.
Doug.
D.
I'm sorry if someone already pointed this out, but I just ran into it
and missed a lot of e-mails on this list lately.
If you're build has a compile error, and then you fix it and then you
build again, it seems you get an infamous:
/cygdrive/c/Eclipse/workspaces/android-sdk/.test/Test/obj/local/armeabi/objs/test2//test.o.d:1:
*** target pattern contains no `%'. Stop.
Looking at test.o.d, I see Windows paths.
So I removed my objs directory and launched the build again (simply
doing a clean resulted in the same error). And low and behold, the .d
file contains cygwin paths. eh?
Is this considered a bug? I really, really want to support the
official NDK with the CDT, but fighting cygwin isn't in my plans, at
least not this much. I won't get into how much hassle it's been just
to get the CDT to call make appropriately.
Sorry for the rant.
Doug.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
David,
Since you mentioned that a update is coming soon. May I know will the this update includes sip support for emulator?
--
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
I'd also like to see a fix for msys. If cygpath isn't in your path,
don't call it. Everything else seems to be working fine.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
I've noticed another dependency related problem, even with the fixes
to the dependency file generation mentioned above.
When a header file is changed, the associated .cpp file is not
recompiled, even when it is properly listed in the .d file as a
dependency. Has anyone else had this problem?
The .o file is correctly recompiled when the .cpp file is changed, but
it is not recompiled when any of the headers are changed.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
One more fix, this time with gusto!
The -MT solution above was very close, but the following minor change,
which uses -MT '$$(PROJECT_OBJ)' instead of using the host-path macro,
fixes all known issues, including proper rebuilding of EXTERNAL source
files when a header changes:
$(hide) $$(PRIVATE_CC) -MM -MP -MT '$$(PRIVATE_OBJ)' -MF $$
(PRIVATE_DEPS) $$(PRIVATE_CFLAGS) $$(call host-path,$$(PRIVATE_SRC))The host-path macro converts from Windows to cygwin paths (see
definitions.mk:118), but the $$(PROJECT_OBJ) variable is already a
cygwin path, works fine as input to gcc, and, regardless, we convert
Windows to cygwin paths using the sed (or awk) script anyway.
As a result, I don't think I need to file a bug on this issue. David,
please let me know if you would still like me to file a bug along with
the suggested fix for tracking.
> ...
>
> read more »
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> you mean is that it doesn't matter which form is used in the generatedYeah, that's what I meant.
> dependency file since it will later be translated by the awk script, which
> is true.
External headers are fixed by this change because the -MT option
> I still don't understand why the header dependency stuff doesn't
> work or is fixed by that change, but will test.
specifies the exact text that is entered into the .d file for the
target. The problem with external dependencies is that make was
referring to the same file using two different absolute paths. The
main rule for the .cpp file had relative directories within an
absolute path (e.g. /cygpath/c/foo/bar/../../bam/boom/goo.cpp) whereas
the cygpath -m done by the host-path macro in definitions.mk resulted
in /cygpath/c/bam/boom/goo.cpp. By switching to $$(PROJECT_OBJ)
instead of '$$(call host-path,$$(PRIVATE_OBJ)), the .d file now used
the former, absolute-with-relative path.
For future reference, and as a tip for ndk-build and make debugging, I
tracked this down using the -p option, which prints out the make
database, including dependency rules. By careful examination of what
was going on for local vs. external files, I was able to see that
there were two separate dependency entries for external files, and
only one for internal files. Usually, I just pass the -p output
through grep to minimize the verbosity.
Will do. Happy to help. Thanks,
> Oh, for God's sake, please file a bug. There are so many things going on
> that I'll probably forget about the problem if you don't !
> Or better, submit a patch to r.android.com :-)
Wex
--
Doug.