* i2c-tools: add Android.mk
@ 2015-02-27 21:05 Angelo Compagnucci
[not found] ` <CA+TH9VkQzJaSa0okxK+s1ukpaqgiWegh3uumEb63LzZwBjV4nA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Compagnucci @ 2015-02-27 21:05 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA; +Cc: jdelvare-l3A5Bk7waGM
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
Hi Jean,
This patch adds an Android.mk to compile i2c-tools under Android.
Hope this helps!
--
Profile: http://it.linkedin.com/in/compagnucciangelo
[-- Attachment #2: i2c-tools-add-android-mk.patch --]
[-- Type: text/x-patch, Size: 1674 bytes --]
Index: Android.mk
===================================================================
--- Android.mk (revision 0)
+++ Android.mk (working copy)
@@ -0,0 +1,53 @@
+LOCAL_PATH:= $(call my-dir)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := optional
+LOCAL_C_INCLUDES += $(LOCAL_PATH) $(LOCAL_PATH)/$(KERNEL_DIR)/include
+LOCAL_SRC_FILES := tools/i2cbusses.c tools/util.c
+LOCAL_MODULE := i2c-tools
+include $(BUILD_STATIC_LIBRARY)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := optional
+LOCAL_SRC_FILES:=tools/i2cdetect.c
+LOCAL_MODULE:=i2cdetect
+LOCAL_CPPFLAGS += -DANDROID
+LOCAL_SHARED_LIBRARIES:=libc
+LOCAL_STATIC_LIBRARIES := i2c-tools
+LOCAL_C_INCLUDES += $(LOCAL_PATH) $(LOCAL_PATH)/$(KERNEL_DIR)/include
+include $(BUILD_EXECUTABLE)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := optional
+LOCAL_SRC_FILES:=tools/i2cget.c
+LOCAL_MODULE:=i2cget
+LOCAL_CPPFLAGS += -DANDROID
+LOCAL_SHARED_LIBRARIES:=libc
+LOCAL_STATIC_LIBRARIES := i2c-tools
+LOCAL_C_INCLUDES += $(LOCAL_PATH) $(LOCAL_PATH)/$(KERNEL_DIR)/include
+include $(BUILD_EXECUTABLE)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := optional
+LOCAL_SRC_FILES:=tools/i2cset.c
+LOCAL_MODULE:=i2cset
+LOCAL_CPPFLAGS += -DANDROID
+LOCAL_SHARED_LIBRARIES:=libc
+LOCAL_STATIC_LIBRARIES := i2c-tools
+LOCAL_C_INCLUDES += $(LOCAL_PATH) $(LOCAL_PATH)/$(KERNEL_DIR)/include
+include $(BUILD_EXECUTABLE)
+
+include $(CLEAR_VARS)
+
+LOCAL_MODULE_TAGS := optional
+LOCAL_SRC_FILES:=tools/i2cdump.c
+LOCAL_MODULE:=i2cdump
+LOCAL_CPPFLAGS += -DANDROID
+LOCAL_SHARED_LIBRARIES:=libc
+LOCAL_STATIC_LIBRARIES := i2c-tools
+LOCAL_C_INCLUDES += $(LOCAL_PATH) $(LOCAL_PATH)/$(KERNEL_DIR)/include
+include $(BUILD_EXECUTABLE)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
[not found] ` <CA+TH9VkQzJaSa0okxK+s1ukpaqgiWegh3uumEb63LzZwBjV4nA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-03-16 9:16 ` Jean Delvare
[not found] ` <20150316101626.2c7a02be-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Jean Delvare @ 2015-03-16 9:16 UTC (permalink / raw)
To: Angelo Compagnucci; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA
Hi Angelo,
On Fri, 27 Feb 2015 22:05:12 +0100, Angelo Compagnucci wrote:
> This patch adds an Android.mk to compile i2c-tools under Android.
>
> Hope this helps!
I have to say I don't know what to do with this.
For one thing, I don't really understand why Android needs a separate
build mechanism when all other Linux and BSD incarnations seem to be
fine with the standard Makefile. GNU make certainly runs on Android,
right? And you would typically cross-compile for Android anyway. Also I
have not seen an Android.mk file in any other project I'm working on,
and I can't see why i2c-tools would be special in this respect.
For another, the current build mechanism is a modular one where the
main Makefile includes Module.mk files present in the different
subdirectories. I like this design and having a single Android.mk file
at the root of the project is inconsistent and breaks that design.
As a summary I don't see why anything special is needed for Android,
but if something like that is really needed then it should respect the
existing modular design.
Now if anyone has a more educated view on this than I do, please speak
up. Android is really not my thing (as a developer, I mean.)
Thanks,
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
[not found] ` <20150316101626.2c7a02be-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
@ 2015-03-16 9:30 ` Angelo Compagnucci
2015-06-17 10:29 ` Wolfram Sang
1 sibling, 0 replies; 7+ messages in thread
From: Angelo Compagnucci @ 2015-03-16 9:30 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA
Dear Jean Delvare,
The Android build system requires an Android.mk into the root dir of a
package. Android simply doesn't use recursive makefile.
So if you want to drop i2c-tools into the android source tree to
having it compiled by the Android build system, you should add an
Android.mk manually.
Probably, the other projects you mention are compiled externelly from
the Android build system with an external toolchain, so calling make
with the right options is not a problem.
I think that all projects potentially interesting in the Android world
should adopt an Android.mk to be easily buildable into the Android
build system.
Sincerely, Angelo.
2015-03-16 10:16 GMT+01:00 Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>:
> Hi Angelo,
>
> On Fri, 27 Feb 2015 22:05:12 +0100, Angelo Compagnucci wrote:
>> This patch adds an Android.mk to compile i2c-tools under Android.
>>
>> Hope this helps!
>
> I have to say I don't know what to do with this.
>
> For one thing, I don't really understand why Android needs a separate
> build mechanism when all other Linux and BSD incarnations seem to be
> fine with the standard Makefile. GNU make certainly runs on Android,
> right? And you would typically cross-compile for Android anyway. Also I
> have not seen an Android.mk file in any other project I'm working on,
> and I can't see why i2c-tools would be special in this respect.
>
> For another, the current build mechanism is a modular one where the
> main Makefile includes Module.mk files present in the different
> subdirectories. I like this design and having a single Android.mk file
> at the root of the project is inconsistent and breaks that design.
>
> As a summary I don't see why anything special is needed for Android,
> but if something like that is really needed then it should respect the
> existing modular design.
>
> Now if anyone has a more educated view on this than I do, please speak
> up. Android is really not my thing (as a developer, I mean.)
>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
[not found] ` <20150316101626.2c7a02be-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2015-03-16 9:30 ` Angelo Compagnucci
@ 2015-06-17 10:29 ` Wolfram Sang
2015-06-17 10:38 ` Angelo Compagnucci
1 sibling, 1 reply; 7+ messages in thread
From: Wolfram Sang @ 2015-06-17 10:29 UTC (permalink / raw)
To: Jean Delvare; +Cc: Angelo Compagnucci, linux-i2c-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
> Now if anyone has a more educated view on this than I do, please speak
> up. Android is really not my thing (as a developer, I mean.)
While working again on adding i2ctransfer to i2c-tools, it became clear
that this android makefile would need an update for it, too. And since
nobody of us is using i2c-tools on android, nobody can provide a tested
update. So, it would indeed be easier if the android universe would
figure a way in their sphere. So, I agree with Jean.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
2015-06-17 10:29 ` Wolfram Sang
@ 2015-06-17 10:38 ` Angelo Compagnucci
[not found] ` <CA+TH9Vm7oKH43S7j5G2_iQi7cF=y3G04V_nrswQ+6E1J6JNbOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Compagnucci @ 2015-06-17 10:38 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Hi Wolfram,
2015-06-17 12:29 GMT+02:00 Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>:
>
>> Now if anyone has a more educated view on this than I do, please speak
>> up. Android is really not my thing (as a developer, I mean.)
>
> While working again on adding i2ctransfer to i2c-tools, it became clear
> that this android makefile would need an update for it, too. And since
> nobody of us is using i2c-tools on android, nobody can provide a tested
> update.
Nobody but me! Actually I'm using it and I had the need for it.
Probably there are other people reinventing the wheel outside this
mailinglist. Try to google for it.
> So, it would indeed be easier if the android universe would
> figure a way in their sphere. So, I agree with Jean.
I think it's more a matter of a makefile approach. They use a non
recursive one (recommended by several papers[1]) and it's up to
external projects if embrace it or no. Honestly I think that a
minuscule file with really low maintenance should be added.
I'm glad to prepare a new patch if maintainership is interested!
Sincerely, Angelo
[1] http://aegis.sourceforge.net/auug97.pdf
--
Profile: http://it.linkedin.com/in/compagnucciangelo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
[not found] ` <CA+TH9Vm7oKH43S7j5G2_iQi7cF=y3G04V_nrswQ+6E1J6JNbOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-06-17 10:46 ` Wolfram Sang
2015-06-17 12:13 ` Jean Delvare
1 sibling, 0 replies; 7+ messages in thread
From: Wolfram Sang @ 2015-06-17 10:46 UTC (permalink / raw)
To: Angelo Compagnucci; +Cc: Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
> I think it's more a matter of a makefile approach. They use a non
> recursive one (recommended by several papers[1]) and it's up to
> external projects if embrace it or no. Honestly I think that a
> minuscule file with really low maintenance should be added.
Isn't there a central place where these android makefiles are collected?
It reminds me a bit to buildroot which has recipes for packages like
i2c-tools to include it into a rootfs for embedded systems. There,
buildroot is the central place.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: i2c-tools: add Android.mk
[not found] ` <CA+TH9Vm7oKH43S7j5G2_iQi7cF=y3G04V_nrswQ+6E1J6JNbOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-17 10:46 ` Wolfram Sang
@ 2015-06-17 12:13 ` Jean Delvare
1 sibling, 0 replies; 7+ messages in thread
From: Jean Delvare @ 2015-06-17 12:13 UTC (permalink / raw)
To: Angelo Compagnucci; +Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
On Wed, 17 Jun 2015 12:38:54 +0200, Angelo Compagnucci wrote:
> Hi Wolfram,
>
> 2015-06-17 12:29 GMT+02:00 Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>:
> >
> >> Now if anyone has a more educated view on this than I do, please speak
> >> up. Android is really not my thing (as a developer, I mean.)
> >
> > While working again on adding i2ctransfer to i2c-tools, it became clear
> > that this android makefile would need an update for it, too. And since
> > nobody of us is using i2c-tools on android, nobody can provide a tested
> > update.
>
> Nobody but me! Actually I'm using it and I had the need for it.
> Probably there are other people reinventing the wheel outside this
> mailinglist. Try to google for it.
We're not saying the immediate need doesn't exist. We're only
questioning whether the i2c-tools repository is the right place for the
extra file. This questioning is reinforced by the fact that I never saw
any Andoid.mk file in any other upstream project I'm working on.
It really reminds me of rpm spec files or Debian-specific files hosted
by upstream projects. My experience is that these files bitrot over time
because the upstream maintainers don't need them and often can't test
them. They are better maintained somewhere else.
(And then again I don't understand why they can't just use "make" as
everybody else.)
> > So, it would indeed be easier if the android universe would
> > figure a way in their sphere. So, I agree with Jean.
>
> I think it's more a matter of a makefile approach. They use a non
> recursive one (recommended by several papers[1]) and it's up to
i2c-tools's Makefile is not recursive. In fact it's derived from
lm-sensors' Makefile, which itself was designed based on the paper
"Recursive Make Considered Harmful" - the one you just mentioned. Ah,
irony ;-)
i2c-tools's Makefile is modular. Not recursive.
> external projects if embrace it or no. Honestly I think that a
> minuscule file with really low maintenance should be added.
>
> I'm glad to prepare a new patch if maintainership is interested!
I'm not.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-06-17 12:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-27 21:05 i2c-tools: add Android.mk Angelo Compagnucci
[not found] ` <CA+TH9VkQzJaSa0okxK+s1ukpaqgiWegh3uumEb63LzZwBjV4nA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-16 9:16 ` Jean Delvare
[not found] ` <20150316101626.2c7a02be-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2015-03-16 9:30 ` Angelo Compagnucci
2015-06-17 10:29 ` Wolfram Sang
2015-06-17 10:38 ` Angelo Compagnucci
[not found] ` <CA+TH9Vm7oKH43S7j5G2_iQi7cF=y3G04V_nrswQ+6E1J6JNbOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-17 10:46 ` Wolfram Sang
2015-06-17 12:13 ` Jean Delvare
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).