[OpenWrt-Devel,1/8] ncurses: add cygwin compatibility
diff mbox series

Message ID 20191008010225.8822-1-rosenp@gmail.com
State Rejected
Delegated to: Petr Štetiar
Headers show
Series
  • [OpenWrt-Devel,1/8] ncurses: add cygwin compatibility
Related show

Commit Message

Rosen Penev Oct. 8, 2019, 1:02 a.m. UTC
From: Alexey Loukianov <lx2@lexa2.ru>

* Properly handle ".exe" suffix for cygwin.

Signed-off-by: Alexey Loukianov <lx2@lexa2.ru>
(bumped PKG_RELEASE)
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 package/libs/ncurses/Makefile | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

Comments

Paul Oranje Oct. 8, 2019, 10:14 a.m. UTC | #1
Hi,

> Op 8 okt. 2019, om 03:02 heeft Rosen Penev <rosenp@gmail.com> het volgende geschreven:
> 
> From: Alexey Loukianov <lx2@lexa2.ru>
> 
> * Properly handle ".exe" suffix for cygwin.
> 
> Signed-off-by: Alexey Loukianov <lx2@lexa2.ru>
> (bumped PKG_RELEASE)
> Signed-off-by: Rosen Penev <rosenp@gmail.com>

Two questions:
Is there any cover to this series of 8 patches that seemingly aim to add cygwin compatibility ?
And why would this project ever need cygwin compatibility, which will likely require quite some maintenance efforts ?

Any effort to make .exe files callable senses like getting into troubled waters, even if more analysis would prove such fears aren't warranted.

In short: to what purpose, what use-case ?

Regards,
Paul
Alberto Bursi Oct. 8, 2019, 12:57 p.m. UTC | #2
On 08/10/19 12:14, Paul Oranje wrote:
> Hi,
>
>> Op 8 okt. 2019, om 03:02 heeft Rosen Penev <rosenp@gmail.com> het volgende geschreven:
>>
>> From: Alexey Loukianov <lx2@lexa2.ru>
>>
>> * Properly handle ".exe" suffix for cygwin.
>>
>> Signed-off-by: Alexey Loukianov <lx2@lexa2.ru>
>> (bumped PKG_RELEASE)
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> Two questions:
> Is there any cover to this series of 8 patches that seemingly aim to add cygwin compatibility ?
> And why would this project ever need cygwin compatibility, which will likely require quite some maintenance efforts ?
>
> Any effort to make .exe files callable senses like getting into troubled waters, even if more analysis would prove such fears aren't warranted.
>
> In short: to what purpose, what use-case ?
>
> Regards,
> Paul
>
>
Yeah it seems these patches are for using the build system with cygwin. 
I think there should be more explanation on why you want that.

-Alberto
Petr Štetiar Oct. 9, 2019, 8:28 p.m. UTC | #3
Rosen Penev <rosenp@gmail.com> [2019-10-07 18:02:18]:

> * Properly handle ".exe" suffix for cygwin.

why?
Paul Oranje Oct. 15, 2019, 8:12 a.m. UTC | #4
> Op 8 okt. 2019, om 14:57 heeft Alberto Bursi <bobafetthotmail@gmail.com> het volgende geschreven:
> ...
> Yeah it seems these patches are for using the build system with cygwin. I think there should be more explanation on why you want that.

Dear Rosen, could you please answer to what purpose you summitted this set of patches ?
Regards,
Paul
Rosen Penev Oct. 16, 2019, 6:36 p.m. UTC | #5
On Tue, Oct 15, 2019 at 1:12 AM Paul Oranje <por@oranjevos.nl> wrote:
>
>
>
> > Op 8 okt. 2019, om 14:57 heeft Alberto Bursi <bobafetthotmail@gmail.com> het volgende geschreven:
> > ...
> > Yeah it seems these patches are for using the build system with cygwin. I think there should be more explanation on why you want that.
>
> Dear Rosen, could you please answer to what purpose you summitted this set of patches ?
I have a branch with these patches. Thought it would be good to upstream.

They're not really invasive. Some, like the dosfstools are also
consistency updates.
> Regards,
> Paul
Petr Štetiar Oct. 22, 2019, 10:43 a.m. UTC | #6
Rosen Penev <rosenp@gmail.com> [2019-10-16 11:36:22]:

> Some, like the dosfstools are also consistency updates.

If you're talking about patch 3 of 8 "tools/dosfstools: Replace iconv patch with
upstream submission" then it looks like your suggested fix[1] was replaced by
more comphrensive fix[2] and you were happy with the result.

So perhaps bumping dosfstools would make more sense now?

1. https://github.com/dosfstools/dosfstools/pull/124
2. https://github.com/dosfstools/dosfstools/pull/126

-- ynezz
Rosen Penev Oct. 23, 2019, 7:46 p.m. UTC | #7
On Tue, Oct 22, 2019 at 3:43 AM Petr Štetiar <ynezz@true.cz> wrote:
>
> Rosen Penev <rosenp@gmail.com> [2019-10-16 11:36:22]:
>
> > Some, like the dosfstools are also consistency updates.
>
> If you're talking about patch 3 of 8 "tools/dosfstools: Replace iconv patch with
> upstream submission" then it looks like your suggested fix[1] was replaced by
> more comphrensive fix[2] and you were happy with the result.
>
> So perhaps bumping dosfstools would make more sense now?
There's no new version. That comprehensive fix is a pain to backport.
>
> 1. https://github.com/dosfstools/dosfstools/pull/124
> 2. https://github.com/dosfstools/dosfstools/pull/126
>
> -- ynezz

Patch
diff mbox series

diff --git a/package/libs/ncurses/Makefile b/package/libs/ncurses/Makefile
index e22eb2b893..07e0fb5c5f 100644
--- a/package/libs/ncurses/Makefile
+++ b/package/libs/ncurses/Makefile
@@ -9,7 +9,7 @@  include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ncurses
 PKG_VERSION:=6.1
-PKG_RELEASE:=5
+PKG_RELEASE:=6
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=@GNU/$(PKG_NAME)
@@ -26,6 +26,12 @@  PKG_BUILD_DEPENDS:=ncurses/host
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/host-build.mk
 
+ifeq (CYGWIN,$(findstring CYGWIN,$(HOST_OS)))
+EXEC_SUFFIX:=.exe
+else
+EXEC_SUFFIX:=
+endif
+
 define Package/terminfo
   SECTION:=libs
   CATEGORY:=Libraries
@@ -167,7 +173,7 @@  endef
 
 define Host/Compile
 	$(MAKE) -C $(HOST_BUILD_DIR) libs
-	$(MAKE) -C $(HOST_BUILD_DIR)/progs tic
+	$(MAKE) -C $(HOST_BUILD_DIR)/progs tic$(EXEC_SUFFIX)
 endef
 
 $(eval $(call HostBuild))