Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support android build #4

Merged
merged 1 commit into from Aug 8, 2013
Merged

support android build #4

merged 1 commit into from Aug 8, 2013

Conversation

@aydinkim
Copy link

aydinkim commented Aug 7, 2013

Support android build
This commit does not affect to each submodule's original standalone build system.

@@ -183,10 +188,10 @@ CFLAGS += -I$(VPATH)/src -I$(VPATH)/include -I$(VPATH)/../../wapcaplet/libwapcap
.PHONY: all
all: libcss.dummy

PROPERTY_PARSER_GEN_OBJS = $(patsubst %.c,%.o,$(PROPERTY_PARSER_GEN_C_SRC))
PROPERTY_PARSER_GEN_OBJS = $(patsubst %.c,%.o_sys,$(PROPERTY_PARSER_GEN_C_SRC))

This comment has been minimized.

Copy link
@metajack

metajack Aug 7, 2013

Contributor

is _sys a typical naming convention?

This comment has been minimized.

Copy link
@aydinkim

aydinkim Aug 8, 2013

Author

I think No.
there is no need to do this on linux, but without this renaming work of property parser generator object, the machine can not distinguish android 32bit object and linux 64bit object so that occurs error.
when we do cross compile libcss, each host object and target object need to be discriminated.
This is just a reason of renaming.
Do you have any good idea to do this or make name?

metajack added a commit that referenced this pull request Aug 8, 2013
@metajack metajack merged commit 7201286 into servo:master Aug 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.