diff mbox

uclibc: clean-up test suite build command

Message ID 1404149181-18586-1-git-send-email-abrodkin@synopsys.com
State Rejected
Headers show

Commit Message

Alexey Brodkin June 30, 2014, 5:26 p.m. UTC
Starting from uClibc 0.9.32 this cleaned-up command builds tests flawlessly.
For 0.9.31 it lead to build failure, but assuming there're close to zero
users who is going to test outdated uClibc library on obsolete
(in Buildroot) AVR32 architecture I thin it worth applying.

Still it's possible to have 2 variants at the same time until AVR32 is not gone:
1. Old implementation used strictly for uClibc 0.9.31
2. New implementation for all other versions

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
---
 package/uclibc/uclibc.mk | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Comments

Thomas Petazzoni June 30, 2014, 6:07 p.m. UTC | #1
Dear Alexey Brodkin,

On Mon, 30 Jun 2014 21:26:21 +0400, Alexey Brodkin wrote:
> Starting from uClibc 0.9.32 this cleaned-up command builds tests flawlessly.
> For 0.9.31 it lead to build failure, but assuming there're close to zero
> users who is going to test outdated uClibc library on obsolete
> (in Buildroot) AVR32 architecture I thin it worth applying.
> 
> Still it's possible to have 2 variants at the same time until AVR32 is not gone:
> 1. Old implementation used strictly for uClibc 0.9.31
> 2. New implementation for all other versions
> 
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Unfortunately, unless this cleaned-up version brings significant
benefits, I believe the best option is to keep things as is until AVR32
support is really deprecated and removed from Buildroot, so that we can
drop support for 0.9.31.

Thanks,

Thomas
Alexey Brodkin July 1, 2014, 10:27 a.m. UTC | #2
Hi Thomas,

On Mon, 2014-06-30 at 20:07 +0200, Thomas Petazzoni wrote:
> Unfortunately, unless this cleaned-up version brings significant
> benefits, I believe the best option is to keep things as is until AVR32
> support is really deprecated and removed from Buildroot, so that we can
> drop support for 0.9.31.

That's fine for me. Anyways patch is published and at any point anybody
may apply it whether local or even upstream.

-Alexey
Alexey Brodkin March 25, 2015, 7:49 a.m. UTC | #3
Hi Thomas,

On Mon, 2014-06-30 at 20:07 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Mon, 30 Jun 2014 21:26:21 +0400, Alexey Brodkin wrote:
> > Starting from uClibc 0.9.32 this cleaned-up command builds tests flawlessly.
> > For 0.9.31 it lead to build failure, but assuming there're close to zero
> > users who is going to test outdated uClibc library on obsolete
> > (in Buildroot) AVR32 architecture I thin it worth applying.
> > 
> > Still it's possible to have 2 variants at the same time until AVR32 is not gone:
> > 1. Old implementation used strictly for uClibc 0.9.31
> > 2. New implementation for all other versions
> > 
> > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> 
> Unfortunately, unless this cleaned-up version brings significant
> benefits, I believe the best option is to keep things as is until AVR32
> support is really deprecated and removed from Buildroot, so that we can
> drop support for 0.9.31.

Now when AVR32 support is finally dropped do you think this patch might
be accepted?

It still applies flawlessly on current master.

I build tested it on ARC and ARM. Note on ARM uClibc tests
(BR2_UCLIBC_INSTALL_TEST_SUITE) will be only compiled without errors
with uClibc-ng (BR2_UCLIBC_VERSION_NG), either BR2_UCLIBC_VERSION_0_9_33
or BR2_UCLIBC_VERSION_SNAPSHOT will fail on testsuite compilation but
that has nothing to do with current patch.

-Alexey
Thomas Petazzoni March 25, 2015, 4:39 p.m. UTC | #4
Dear Alexey Brodkin,

On Wed, 25 Mar 2015 07:49:24 +0000, Alexey Brodkin wrote:

> > Unfortunately, unless this cleaned-up version brings significant
> > benefits, I believe the best option is to keep things as is until AVR32
> > support is really deprecated and removed from Buildroot, so that we can
> > drop support for 0.9.31.
> 
> Now when AVR32 support is finally dropped do you think this patch might
> be accepted?

Yes, sure! AVR32 / supporting old uClibc versions was the only reason
to keep the old way around. Now that AVR32 is gone, all clean-ups we
can do following this removal are very welcome.

Thomas
Alexey Brodkin April 20, 2015, 8:39 a.m. UTC | #5
Hi Thomas,

On Wed, 2015-03-25 at 17:39 +0100, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Wed, 25 Mar 2015 07:49:24 +0000, Alexey Brodkin wrote:
> 
> > > Unfortunately, unless this cleaned-up version brings significant
> > > benefits, I believe the best option is to keep things as is until AVR32
> > > support is really deprecated and removed from Buildroot, so that we can
> > > drop support for 0.9.31.
> > 
> > Now when AVR32 support is finally dropped do you think this patch might
> > be accepted?
> 
> Yes, sure! AVR32 / supporting old uClibc versions was the only reason
> to keep the old way around. Now that AVR32 is gone, all clean-ups we
> can do following this removal are very welcome.

Please treat this as a gentle reminder. I'm wondering if that pretty
straight-forward change has a chance for being applied?

From your previous answer I understood that you\re in general fine with
clean-up stuff like that.

-Alexey
Thomas Petazzoni April 20, 2015, 8:58 a.m. UTC | #6
Dear Alexey Brodkin,

On Mon, 20 Apr 2015 08:39:07 +0000, Alexey Brodkin wrote:

> Please treat this as a gentle reminder. I'm wondering if that pretty
> straight-forward change has a chance for being applied?
> 
> From your previous answer I understood that you\re in general fine with
> clean-up stuff like that.

Sure. Can you resend a new version of the patch, so that it shows up in
patchwork?

Thanks,

Thomas
Alexey Brodkin April 20, 2015, 9:10 a.m. UTC | #7
Hi Thomas,

On Mon, 2015-04-20 at 10:58 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Mon, 20 Apr 2015 08:39:07 +0000, Alexey Brodkin wrote:
> 
> > Please treat this as a gentle reminder. I'm wondering if that pretty
> > straight-forward change has a chance for being applied?
> > 
> > From your previous answer I understood that you\re in general fine with
> > clean-up stuff like that.
> 
> Sure. Can you resend a new version of the patch, so that it shows up in
> patchwork?

Sure, done!

-Alexey
diff mbox

Patch

diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index caa5553..0cbd3c8 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -484,12 +484,10 @@  endef
 
 ifeq ($(BR2_UCLIBC_INSTALL_TEST_SUITE),y)
 define UCLIBC_BUILD_TEST_SUITE
-	$(MAKE1) -C $(@D)/test \
+	$(MAKE1) -C $(@D) \
 		$(UCLIBC_MAKE_FLAGS) \
-		ARCH_CFLAGS=-I$(STAGING_DIR)/usr/include \
 		UCLIBC_ONLY=1 \
-		TEST_INSTALLED_UCLIBC=1 \
-		compile
+		test_compile
 endef
 endif