Le 19/04/2012 16:40, Mirko Vogt a écrit :
On 04/19/2012 04:00 PM, Emmanuel Deloget wrote:
Good catch. In fact, HEAD is likely to never be the right choice, even
in other packages. So maybe we can forbid it?
That's what I meant with:
"Since fetching the latest HEAD of any external source is uncommon and
to be avoided anyway (since builds are non-deterministic and changes to
external repositories might result in unpredictable build behaviours)
I'd like to drop the option of fetching trunk/HEAD at all."
My fingers are sometimes too fast for my brain. The resulting code often
contain bugs - and the resulting email often contain junk. Brain says "ok,
I've read that" but the fingers have already types some kind of nonsensical
answer.
I apologize.
I also just found another issue with HEAD (in this specific case): we are
not able to correctly specify LIBC_SO_VERSION, meaning that building
base-files fails (as we cannot copy the libc shared library).
$ grep EGLIBC_ .config | grep -v OPTION
# CONFIG_EGLIBC_VERSION_2_12 is not set
# CONFIG_EGLIBC_VERSION_2_13 is not set
# CONFIG_EGLIBC_VERSION_2_14 is not set
CONFIG_EGLIBC_VERSION_TRUNK=y
CONFIG_EGLIBC_TRUNK_REVISION="HEAD"
CONFIG_EGLIBC_REVISION="HEAD"
CONFIG_EGLIBC_VERSION="trunk"
$ make package/base-files/compile V=1
make[1] package/base-files/compile
make[2] -C package/opkg host-compile
make[2] -C package/base-files-network compile
make[2] -C package/base-files compile
cp: cannot stat
`/home/me/openwrt/trunk/staging_dir/toolchain-arm_v7-a_gcc-4.6-linaro_eglibc-trunk_eabi/lib/ld-trunk.so':
No such file or directory
make[2]: ***
[/home/me/openwrt/trunk/bin/omap4/packages/libc_trunk-106_omap4.ipk] Error 1
make[1]: *** [package/base-files/compile] Error 2
make -r package/base-files/compile: build failed. Please re-run make with V=99
to see what's going on
make: *** [package/base-files/compile] Erreur 1
Culprit is toolchain/eglibc/Makefile line 79:
define Host/SetToolchainInfo
$(SED) 's,^\(LIBC_TYPE\)=.*,\1=$(PKG_NAME),' $(TOOLCHAIN_DIR)/info.mk
$(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.eglibc.org/,'
$(TOOLCHAIN_DIR)/info.mk
$(SED) 's,^\(LIBC_VERSION\)=.*,\1=$(PKG_VERSION),'
$(TOOLCHAIN_DIR)/info.mk
$(SED) 's,^\(LIBC_SO_VERSION\)=.*,\1=$(PKG_VERSION),'
$(TOOLCHAIN_DIR)/info.mk
endef
Since PKG_VERSION is set to CONFIG_EGLIBC_VERSION, it cannot work. In fact,
it works only in very specific cases - i.e. where the version is not a
maintenance release. Maintenance releases have a version number of the form
x.y.z and CONFIG_EGLIBC_VERSION is x.y only - it's missing a micro version
part. As a consequence, both LIBC_VERSION and LIBC_SO_VERSION will be wrong
if the selected revision refer to a maintenance release (this is the case
for at least 2.12, which is really 2.12.2).
I have no idea on how we can fix this, other than setting the correct
version numbers in the CONFIG_EGLIBC_VERSION.
I can provide a patch to fix the current state, but that would not make
much sense if 2.12 is to be removed from the tree. Of course, such a patch
shall also cure the problem when the user handpick a revision in the eglibc
trunk (but again, this might be removed as well).
I think your ideas to change download.mk make sense and provide benefits
to developers (when $REV is 'HEAD' it should always re-fetch the src
(independent of used SCM)). Quite some people asked yet how to always
fetch HEAD from (custom) repositories and I was missing this
functionality in some custom projects myself.
Unfortunately, it's not enough to get the work done, as the build system
really wants the archive to be present - if I don't save the file, I get
the following error:
A eglibc-trunk-rHEAD/localedef/config.sub
A eglibc-trunk-rHEAD/localedef/vasprintf.c
A eglibc-trunk-rHEAD/localedef/install-sh
Exported revision 18123.
bzcat: Can't open input file
/home/me/openwrt/trunk/dl/eglibc-trunk-rHEAD.tar.bz2: No such file or directory.
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
I think the best course of action is to re-fetch the source in those cases:
* if the package is not prepared yet (i.e. if the user cleans the package
or before the package is built for the first time).
* if the package fails to compile
But we should avoid re-fetching the source once the package has been
successfully built.
For packages, these conditions can be factorized into the following one:
$(PKG_BUILD_DIR)/.built exists. We have a similar file in
I just tested the following:
Index: include/download.mk
===================================================================
--- include/download.mk (révision 31345)
+++ include/download.mk (copie de travail)
@@ -176,8 +176,13 @@
)
download: $(DL_DIR)/$(FILE)
+ ifeq ($(strip $(VERSION)),HEAD)
+ .PHONY: $(DL_DIR)/$(FILE)
+ endif
+
$(DL_DIR)/$(FILE):
mkdir -p $(DL_DIR)
+ [ ! -f $(DL_DIR)/$(FILE) ] || rm -f $(DL_DIR)/$(FILE)
$(if $(DownloadMethod/$(call
dl_method,$(URL),$(PROTO))),$(DownloadMethod/$(call
dl_method,$(URL),$(PROTO))),$(DownloadMethod/unknown))
endef
I believe I'm on the right track, but the patch does not work as intended
(i.e. it fetches the last revision each time I'm doing a make). I'm still
working on something that will Work As Intended, and I keep you informed.
+config OPENWRT_BLEEDING_EDGE
+ bool
+ default y
+
Introducing OPENWRT_BLEEDING_EDGE raises the impression of
over-engineering to me. We still should try to avoid fetching HEAD of
sources (see above), however IF we provide the possibility - which is
opt-in and just for developers anyway - I don't see the point of
"un-hide" respective options first.
Fine with me. That was just yet another idea :)
Do you want me to resubmit a patch without OPENWRT_BLEEDING_EDGE?
PS: Please try to quote only parts in your replies you're explicitly
referring to. Otherwise threads get unreadable and confusing.
Understood. Personnally, I like having all the email history in one email but
I understand that it makes things a bit noisy.
Best regards,
-- Emmanuel Deloget
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
