| Message ID | CA+TH9VkQzJaSa0okxK+s1ukpaqgiWegh3uumEb63LzZwBjV4nA@mail.gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
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,
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@suse.de>: > 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
> 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.
Hi Wolfram, 2015-06-17 12:29 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>: > >> 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
> 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.
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@the-dreams.de>: > > > >> 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.
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)