Opened 8 months ago
Closed 8 months ago
#69521 closed defect (wontfix)
libtextstyle @0.22.5 uses faulty configure option
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | Cc: | ||
Port: | libtextstyle |
Description
On Leopard, Mac OS X 10.5.8, I just observed:
Executing: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_devel_gettext/libtextstyle/work/gettext-0.22.5/libtextstyle" && ./configure --prefix=/opt/local ac_cv_prog_AWK=/usr/bin/awk ac_cv_path_GMSGFMT=: ac_cv_path_GREP=/usr/bin/grep ac_cv_path_MSGFMT=: ac_cv_path_MSGMERGE=: ac_cv_path_SED=/usr/bin/sed ac_cv_path_XGETTEXT=: --disable-csharp gl_cv_func_getcwd_path_max=yes configure: WARNING: unrecognized options: --disable-csharp
Change History (2)
comment:1 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… removed |
---|---|
Owner: | set to ryandesign |
Status: | new → assigned |
Type: | enhancement → defect |
comment:2 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Note: See
TracTickets for help on using
tickets.
Yes I did notice that during the latest update of gettext, but I decided to ignore the message.
The problem is that gettext has multiple configure scripts. When you run the main configure script, it runs the configure scripts in the subprojects for you. I found it difficult to ascertain which configure scripts supported which options. I could be mistaken but it was my impression that the main configure script might say an option is unsupported while a subproject's configure script honors that option.
Originally we were only using the
--disable-csharp
flag in the gettext and gettext-runtime subports. Then we discovered that the gettext-tools-libs subport needed it too. To solve that ticket, I agreed that we should apply the flag for every subport. While it may not be recognized by every subport today, it does no harm to specify an unrecognized flag, and it ensures we won't run into problems if in some future version of gettext which subprojects honor this flag changes.