tcf-agent: bump to version 1.7.0
PATCH 1/1 tcf-agent: bump to version 1.7.0
Build issues with MicroBlaze and PPC64 targets are fixed
--- ...gent-add-install-target-to-the-CMakeLists.patch | 48 ---------- ...-remove-explicit-uses-of-__ptrace_request.patch | 103 --------------------- ...de-canonicalize_file_name-for-all-c-libs-.patch | 46 --------- package/tcf-agent/Config.in | 5 +- package/tcf-agent/tcf-agent.hash | 2 +- package/tcf-agent/tcf-agent.mk | 2 +- 6 files changed, 4 insertions(+), 202 deletions(-) delete mode 100644 package/tcf-agent/0001-agent-add-install-target-to-the-CMakeLists.patch delete mode 100644 package/tcf-agent/0002-linux-remove-explicit-uses-of-__ptrace_request.patch delete mode 100644 package/tcf-agent/0003-linux-provide-canonicalize_file_name-for-all-c-libs-.patch
package/tcf-agent/0001-agent-add-install-target-to-the-CMakeLists.patch deleted +0 -48
@@ -1,48 +0,0 @@ -From 96c43b223c90746cb2f680d6d5e198afc690dd4d Mon Sep 17 00:00:00 2001 -From: Norbert Lange <[email protected]> -Date: Mon, 4 Dec 2017 10:56:45 +0100 -Subject: [PATCH] agent: add install target to the CMakeLists - -It is common for CMake packages to make sure that 'make install' -works properly, and that's what most users expect. - -More specifically, build systems such as Buildroot also expect -'make install' to do the right thing for CMake-based packages - -Signed-off-by: Norbert Lange <[email protected]> ---- - agent/CMakeLists.txt | 14 ++++++++++++++ - 1 file changed, 14 insertions(+) - -diff --git a/agent/CMakeLists.txt b/agent/CMakeLists.txt -index aef15b96..605862b2 100644 ---- a/agent/CMakeLists.txt -+++ b/agent/CMakeLists.txt -@@ -1,6 +1,8 @@ - # -*- cmake -*- - - cmake_minimum_required(VERSION 2.8) -+project(tcfagent C) -+include(GNUInstallDirs) - - set(CMAKE_COLOR_MAKEFILE OFF) - -@@ -43,3 +45,15 @@ message(STATUS "machine:" ${TCF_MACHINE}) - - add_executable(agent tcf/main/main.c) - target_link_libraries(agent ${TCF_LIB_NAME}) -+ -+# executable and library cant have the same target name, -+# but we can rename the output -+set_target_properties(agent -+ PROPERTIES OUTPUT_NAME tcf-agent) -+ -+# add target to install all outputs -+install(TARGETS agent ${TCF_LIB_NAME} -+ RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR} -+ LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} -+ ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} -+) --- -2.15.1 -
package/tcf-agent/0002-linux-remove-explicit-uses-of-__ptrace_request.patch deleted +0 -103
103 lines not on this page · raw message
package/tcf-agent/0003-linux-provide-canonicalize_file_name-for-all-c-libs-.patch deleted +0 -46
46 lines not on this page · raw message
package/tcf-agent/Config.in +2 -3
@@ -28,9 +28,8 @@ config BR2_PACKAGE_TCF_AGENT_ARCH default "i386" if BR2_i386 && !BR2_ARCH="i686" default "x86_64" if BR2_x86_64 default "powerpc" if BR2_powerpc || BR2_powerpcle -# those architectures fail to build currently -# default "ppc64" if BR2_powerpc64 || BR2_powerpc64le -# default "microblaze" if BR2_microblaze || BR2_microblazeel + default "ppc64" if BR2_powerpc64 || BR2_powerpc64le + default "microblaze" if BR2_microblaze || BR2_microblazeel config BR2_PACKAGE_TCF_AGENT_ARCH_SUPPORTS bool
package/tcf-agent/tcf-agent.hash +1 -1
@@ -1,5 +1,5 @@ # Locally computed: -sha256 94e9277a52929791417d59b515235bf28ca29ffb05c9e89ad331ebc3256fb5df org.eclipse.tcf.agent-1.6.0.tar.gz +sha256 2f8c7be8a0bf7c86c72fd5680bc19a9e8f98792d40c94a0fee30ceb6428b8f33 org.eclipse.tcf.agent-1.7.0.tar.gz # Hash for license files: sha256 f82d01b74a513bd3504d08136026a5ac2a7e6ff62ebcde391fa74aa222d11ce0 agent/edl-v10.html
package/tcf-agent/tcf-agent.mk +1 -1
@@ -4,7 +4,7 @@ # ################################################################################ -TCF_AGENT_VERSION = 1.6.0 +TCF_AGENT_VERSION = 1.7.0 # the tar.xz link was broken the time this file got authored TCF_AGENT_SOURCE = org.eclipse.tcf.agent-$(TCF_AGENT_VERSION).tar.gz TCF_AGENT_SITE = http://git.eclipse.org/c/tcf/org.eclipse.tcf.agent.git/snapshot
Signature · 1 line
2.16.2
PATCH 1/1 tcf-agent: bump to version 1.7.0
Hello,
Quoted 3 lines · Eugene Tarassov
Build issues with MicroBlaze and PPC64 targets are fixed
Signed-off-by Eugene Tarassov <[email protected]>
Thanks Eugene for this patch. However, Norbert had already sent a patch to bump to 1.7.0, and his patch raised a number of questions that haven't been answered:
http://patchwork.ozlabs.org/patch/880414/
In particular, Norbert submission was adding two patches to fix build issues, and doing a lot more changes in tcf-agent.mk. I'm wondering why your patch is so different, and doesn't include Norbert changes.
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 tcf-agent: bump to version 1.7.0
Hi Thomas,
I was not aware Norbert had already sent a patch.
His patch appears to make other changes in addition to selecting newer version, like switching to make from cmake, some changes from after 1.7.0, and support for static linking.
My goal was less ambitious: just version up to 1.7.0 - for now, and delete old patches - they are not needed anymore because of upstream fixes. I'm new to Buildroot. So far, I don't even understand the need to switch to make or to support static linking of tcf-agent.
Anyway, I, personally, would prefer to handle tcf-agent issues upstream, through eclipse.org, without having patches in the Buildroot package.
Regards,
Eugene
Quoted 19 lines · Thomas Petazzoni
Hello,
Quoted 3 lines · Eugene Tarassov
Build issues with MicroBlaze and PPC64 targets are fixed
Signed-off-by Eugene Tarassov <[email protected]>Thanks Eugene for this patch. However, Norbert had already sent a patch to bump to 1.7.0, and his patch raised a number of questions that haven't been answered:
http://patchwork.ozlabs.org/patch/880414/In particular, Norbert submission was adding two patches to fix build issues, and doing a lot more changes in tcf-agent.mk. I'm wondering why your patch is so different, and doesn't include Norbert changes.
Thanks,
Thomas
PATCH 1/1 tcf-agent: bump to version 1.7.0
Hello,
there seems to be a misunderstanding, I probably should have refered to the patch directly.
@Thomas: Part of the discussion resides in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529417,
Eugene is the the maintainer of tcf-agent and I advised him to put his mail in DEVELOPERS,
as otherwise I have to piggyback issues and fixes around projects. Also there are apparently multiple (closed source) projects using tcf-agent, so a my fixes for linux
might break other stuff.
I switched from CMake to regular Makefiles for the same reason, the later is better supported upstream,
and support detecting headers/functions/libraries from the system. Getting CMake to parity would be alot
work.
@Eugene: buildroot allows static linking, which can come handy for stuff like initial ramdisks which only need a
small set of tools (eg. only busybox without any libraries)
I will try to respond to Thomas' requests for the patch this weekend, but can you look at the empty ranlib call?
My solution would be to set the makerule to
$(BINDIR)/libtcf$(EXTLIB) : $(OFILES)
$(AR) $(AR_FLAGS) $(AR_OUT_F)$@ $^
$(RANLIB) $@(and fixup the variable definitions in Makefile.inc)
Norbert
2018-04-13 3:50 GMT+02:00 Evgueni Tarassov <[email protected]>:
Quoted 43 lines
Hi Thomas,
I was not aware Norbert had already sent a patch.
His patch appears to make other changes in addition to selecting newer version, like switching to make from cmake, some changes from after 1.7.0, and support for static linking.
My goal was less ambitious: just version up to 1.7.0 - for now, and delete old patches - they are not needed anymore because of upstream fixes. I'm new to Buildroot. So far, I don't even understand the need to switch to make or to support static linking of tcf-agent.
Anyway, I, personally, would prefer to handle tcf-agent issues upstream, through eclipse.org, without having patches in the Buildroot package.Regards,
EugeneQuoted 22 lines · Thomas Petazzoni
Hello,
Quoted 4 lines · Eugene Tarassov
Build issues with MicroBlaze and PPC64 targets are fixed
Signed-off-by Eugene Tarassov <[email protected]>Thanks Eugene for this patch. However, Norbert had already sent a patch to bump to 1.7.0, and his patch raised a number of questions that haven't been answered:
http://patchwork.ozlabs.org/patch/880414/In particular, Norbert submission was adding two patches to fix build issues, and doing a lot more changes in tcf-agent.mk. I'm wondering why your patch is so different, and doesn't include Norbert changes.
Thanks,
Thomas
PATCH 1/1 tcf-agent: bump to version 1.7.0
and just to clean this up:
adding your email to the DEVELOPERS file,
will mean that you are getting contacted on failures on the automated build, and if someone adds patches that modify those sources.
https://buildroot.org/downloads/manual/manual.html#DEVELOPERS
Norbert
2018-04-13 9:50 GMT+02:00 Norbert Lange <[email protected]>:
Quoted 80 lines
Hello,
there seems to be a misunderstanding, I probably should have refered to the patch directly.
@Thomas: Part of the discussion resides in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529417,
Eugene is the the maintainer of tcf-agent and I advised him to put his mail in DEVELOPERS,
as otherwise I have to piggyback issues and fixes around projects. Also there are apparently multiple (closed source) projects using tcf-agent, so a my fixes for linux
might break other stuff.I switched from CMake to regular Makefiles for the same reason, the later is better supported upstream,
and support detecting headers/functions/libraries from the system. Getting CMake to parity would be alot
work.@Eugene: buildroot allows static linking, which can come handy for stuff like initial ramdisks which only need a
small set of tools (eg. only busybox without any libraries)I will try to respond to Thomas' requests for the patch this weekend, but can you look at the empty ranlib call?
My solution would be to set the makerule to$(BINDIR)/libtcf$(EXTLIB) : $(OFILES)
$(AR) $(AR_FLAGS) $(AR_OUT_F)$@ $^ $(RANLIB) $@(and fixup the variable definitions in Makefile.inc)
Norbert
2018-04-13 3:50 GMT+02:00 Evgueni Tarassov <[email protected]>:
Quoted 43 lines
Hi Thomas,
I was not aware Norbert had already sent a patch.
His patch appears to make other changes in addition to selecting newer version, like switching to make from cmake, some changes from after 1.7.0, and support for static linking.
My goal was less ambitious: just version up to 1.7.0 - for now, and delete old patches - they are not needed anymore because of upstream fixes. I'm new to Buildroot. So far, I don't even understand the need to switch to make or to support static linking of tcf-agent.
Anyway, I, personally, would prefer to handle tcf-agent issues upstream, through eclipse.org, without having patches in the Buildroot package.Regards,
EugeneQuoted 22 lines · Thomas Petazzoni
Hello,
Quoted 4 lines · Eugene Tarassov
Build issues with MicroBlaze and PPC64 targets are fixed
Signed-off-by Eugene Tarassov <[email protected]>Thanks Eugene for this patch. However, Norbert had already sent a patch to bump to 1.7.0, and his patch raised a number of questions that haven't been answered:
http://patchwork.ozlabs.org/patch/880414/In particular, Norbert submission was adding two patches to fix build issues, and doing a lot more changes in tcf-agent.mk. I'm wondering why your patch is so different, and doesn't include Norbert changes.
Thanks,
Thomas
PATCH 1/1 tcf-agent: bump to version 1.7.0
In reply to Norbert LangeHello,
Quoted 8 lines · Norbert Lange
@Thomas: Part of the discussion resides in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529417,
Eugene is the the maintainer of tcf-agent and I advised him to put his mail in DEVELOPERS,
as otherwise I have to piggyback issues and fixes around projects. Also there are apparently multiple (closed source) projects using tcf-agent, so a my fixes for linux
might break other stuff.
OK.
Quoted 5 lines
I switched from CMake to regular Makefiles for the same reason, the later is better supported upstream,
and support detecting headers/functions/libraries from the system. Getting CMake to parity would be alot
work.
That is rather odd. A build system like CMake normally helps a lot resolve cross-compilation issues.
Quoted 8 lines
@Eugene: buildroot allows static linking, which can come handy for stuff like initial ramdisks which only need a
small set of tools (eg. only busybox without any libraries)I will try to respond to Thomas' requests for the patch this weekend, but can you look at the empty ranlib call?
My solution would be to set the makerule to
Quoted 5 lines
$(BINDIR)/libtcf$(EXTLIB) : $(OFILES)
$(AR) $(AR_FLAGS) $(AR_OUT_F)$@ $^ $(RANLIB) $@(and fixup the variable definitions in Makefile.inc)
What about sticking to the CMake build system, and fixing whatever issues you have ? This seems like a much more sensible approach than using hand-written Makefiles.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
Thomas Petazzoni
AppliedPATCH 1/1 tcf-agent: bump to version 1.7.0
In reply to Eugene TarassovHello,
Quoted 14 lines · Eugene Tarassov
Build issues with MicroBlaze and PPC64 targets are fixed
Signed-off-by Eugene Tarassov <[email protected]>--- ...gent-add-install-target-to-the-CMakeLists.patch | 48 ---------- ...-remove-explicit-uses-of-__ptrace_request.patch | 103 --------------------- ...de-canonicalize_file_name-for-all-c-libs-.patch | 46 --------- package/tcf-agent/Config.in | 5 +- package/tcf-agent/tcf-agent.hash | 2 +- package/tcf-agent/tcf-agent.mk | 2 +- 6 files changed, 4 insertions(+), 202 deletions(-) delete mode 100644 package/tcf-agent/0001-agent-add-install-target-to-the-CMakeLists.patch delete mode 100644 package/tcf-agent/0002-linux-remove-explicit-uses-of-__ptrace_request.patch delete mode 100644 package/tcf-agent/0003-linux-provide-canonicalize_file_name-for-all-c-libs-.patch
Applied to master, thanks.
Please send follow-up patches to further improve things if needed. Moving from CMake to plain Makefiles is not really considered an improvement, unless it's the decision from upstream to move away from CMake.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 tcf-agent: bump to version 1.7.0
2018-04-13 10:13 GMT+02:00 Thomas Petazzoni <[email protected]>:
Quoted 5 lines
Please send follow-up patches to further improve things if needed. Moving from CMake to plain Makefiles is not really considered an improvement, unless it's the decision from upstream to move away from CMake.
There aren't any features of CMake used,
not for detecting libraries, not for detecting headers, not for getting flags, all of this is missing compared to the Makefile. All that's there is a subset of the fixed flags + logic from other buildsystems.
If that's an improvement for you, then there's not much left to discuss.
Proper CMake support would need all that (at which point it is surely better than make),
and I expect you will get alot of warnings now in builds, since some feature detection macros are missing.
I wont add proper CMake support myself (as I first considered it), as I would have to dissect the information form other build-systems, and keep it current every new version.
Norbert
PATCH 1/1 tcf-agent: bump to version 1.7.0
Hello,
Quoted 10 lines · Norbert Lange
There aren't any features of CMake used,
not for detecting libraries, not for detecting headers, not for getting flags, all of this is missing compared to theMakefile. All that's there is a subset of the fixed flags + logic from other buildsystems.
If that's an improvement for you, then there's not much left to discuss.Proper CMake support would need all that (at which point it is surely better than make),
and I expect you will get alot of warnings now in builds, since some feature detection macros are missing.
I build tcf-agent 1.7.0, using the patch provided by Eugene, and it built without warnings.
Quoted 3 lines
I wont add proper CMake support myself (as I first considered it), as I would have to dissect the information form other build-systems, and keep it current every new version.
Maybe we should just ask Eugene was is the official and upstream-supported build system for tcf-agent. Using CMake instead of hand-written Makefiles definitely makes a lot of sense. It does work today, and if there are some issues with it, they can be fixed.
Look at your patch that was fixing the static linking issue with OpenSSL. CMake has built-in support for detecting libraries using pkg-config, automatically solving such static linking issues.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 tcf-agent: bump to version 1.7.0
2018-04-13 13:18 GMT+02:00 Thomas Petazzoni <[email protected]>:
Quoted 18 lines
Hello,
Quoted 10 lines · Norbert Lange
There aren't any features of CMake used,
not for detecting libraries, not for detecting headers, not for getting flags, all of this is missing compared to theMakefile. All that's there is a subset of the fixed flags + logic from other buildsystems.
If that's an improvement for you, then there's not much left to discuss.Proper CMake support would need all that (at which point it is surely better than make),
and I expect you will get alot of warnings now in builds, since some feature detection macros are missing.I build tcf-agent 1.7.0, using the patch provided by Eugene, and it built without warnings.
Quoted 8 lines
Quoted 3 lines
I wont add proper CMake support myself (as I first considered it), as I would have to dissect the information form other build-systems, and keep it current every new version.
Maybe we should just ask Eugene was is the official and upstream-supported build system for tcf-agent. Using CMake instead of hand-written Makefiles definitely makes a lot of sense. It does work today, and if there are some issues with it, they can be fixed.
Please separate what CMake could do, and what it does in the concrete example, especially in the state it is right NOW.
I already raised this in the Bugzilla, and I cant speak for upstream, but my understanding is that improvements wont originate from upstream.
Quoted 4 lines
Look at your patch that was fixing the static linking issue with OpenSSL. CMake has built-in support for detecting libraries using pkg-config, automatically solving such static linking issues.
I am pretty sure the failure I had with the Makefile is there too. Cant test this today,
but I can tell you that I did not change *from* CMake (which I otherwise try to use everywhere)
without reason.
Use CMake as soon as its properly supported, but not when its the worse choice right now.
Norbert