Bug 235715

Summary: x11-wm/compiz-plugins-main: fails to build when NLS=off
Product: Ports & Packages Reporter: Koichiro Iwao <meta>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Only Me CC: lwhsu, meta, portmaster, samy.mahmoudi, swills
Priority: --- Keywords: needs-patch
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235745
Attachments:
Description Flags
Patch file generated with svn diff
none
Poudriere log none

Description Koichiro Iwao freebsd_committer 2019-02-13 15:44:42 UTC
After r480038, it fails to build when NLS=off. Same as -extra.

checking for intltool-extract... /usr/local/bin/intltool-extract                                                        checking for xgettext... no
checking for msgmerge... no
checking for msgfmt... no
checking for gmsgfmt... no
configure: error: GNU gettext tools not found; required for intltool
===>  Script "configure" failed unexpectedly.
Comment 1 Koichiro Iwao freebsd_committer 2019-02-13 15:46:02 UTC
Samy, added you to CC list FYI.
Comment 2 Samy Mahmoudi 2019-02-13 16:02:33 UTC
(In reply to Koichiro Iwao from comment #1)

Nice catch, thank you. I will definitely work on that one too.
Comment 3 Koichiro Iwao freebsd_committer 2019-02-13 16:20:55 UTC
(In reply to Samy Mahmoudi from comment #2)

We must test both NLS=on/off when adding NLS option. I didn't notice 'cause i didn't test NLS=off.
Comment 4 Samy Mahmoudi 2019-02-13 18:58:05 UTC
Created attachment 201993 [details]
Patch file generated with svn diff

(In reply to Koichiro Iwao from comment #3)

As I mentioned previously (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230908#c7), I need to spend more time to make NLS a real option. I suggest to revert the addition of that option so that users who globally unset NLS can still build.

The explanation is that the upstream configure script does not honor --disable-nls properly, so that setting NLS to off has no real effect at configure time and gettext/intltool are still needed.

- Add USES=gl and update USE_GL
- Add USES=gnome
- Revert the addition of NLS
- Reorder variables to pet portlint
Comment 5 Samy Mahmoudi 2019-02-13 19:11:25 UTC
Created attachment 201994 [details]
Poudriere log

I had already noticed I/O warnings (apparently related to GCONF_SCHEMAS and deletion) some time ago. These were also generated at the end of this log file.

After fixing the other compiz ports by reverting NLS, I may dive into GCONF_SCHEMAS internals...
Comment 6 Koichiro Iwao freebsd_committer 2019-02-14 00:22:34 UTC
(In reply to Samy Mahmoudi from comment #4)

> The explanation is that the upstream configure script does not honor --disable-nls properly, so that setting NLS to off has no real effect at configure 

No worries, do make -VCONFIGURE_ARGS with NLS=on/off. Options framework explicitly sets opposite options.
Comment 7 Samy Mahmoudi 2019-02-14 13:51:45 UTC
(In reply to Koichiro Iwao from comment #6)

make -VCONFIGURE_ARGS does not reveal much:
• with NLS on,  the configure script is launched with --enable-nls
• with NLS off, the congigure script is launched with --disable-nls
I think this is the expected result.

Besides, the configure script does not take any action when launched with the --disable-nls argument. I think this is erroneous: gettext/intltool checks should be disabled, translations should not be merged, *.mo files should neither be produced nor installed, etc.

This looks like an upstream problem: the Compiz team used to distribute their source packages with autotools, but they did not use a proper AM_CONDITIONAL to make gettext/intltool optional.

The first (and ideal) solution to this problem would be to submit a patch upstream so that they regenerate their source package with autotools. But compiz is dead (to such a point that sources are currently fetched from the FreeBSD distribution cache)[1].

The second solution would be to do the job in-place: patch configure.ac and the *.am files to regenerate configure and the make files, at the cost of adding autotools to the build dependencies. We would also get rid of runtime dependencies gettext/intltool when NLS is off.

[1] There is, however, a community around compiz-reloaded and I have already submit changes to the build system to increase portability and eventually port compiz-reloaded to FreeBSD (https://gitlab.com/compiz/compiz-core/merge_requests/121). I think they do not have the time to review my work, so I am seriously thinking to create a new port with the changes done within the FreeBSD port system and to resubmit the changes upstream, independently, in small chunks to ease in review.
Comment 8 Samy Mahmoudi 2019-02-14 16:09:50 UTC
(In reply to Samy Mahmoudi from comment #7)

"I have already submit" should be "I have already submitted", sorry for that.
Comment 9 Koichiro Iwao freebsd_committer 2019-02-14 22:35:22 UTC
Added swills@ to CC list.
Comment 10 Samy Mahmoudi 2019-02-15 07:25:42 UTC
(In reply to Samy Mahmoudi from comment #7)

"We would also get rid of runtime dependencies gettext/intltool when NLS is off" should be "We would also get rid of buildtime dependency intltool and runtime dependency gettext when NLS is off". Sorry again.
Comment 11 Samy Mahmoudi 2020-06-19 20:41:13 UTC
Hi all,

On the one hand, I should have reverted the introduction of that NLS option, since setting NLS to off prevent the build from succeeding. In addition, as stated in comment 7, gettext can not be disabled easily at the moment.

On the other hand, I have made Compiz Reloaded migrate from intltool to gettext (upstream):

https://gitlab.com/compiz/compiz-plugins-main/-/merge_requests/82

Still WIP, but we now may be able to disable gettext more easily so that NLS=off becomes functional.
Comment 12 Samy Mahmoudi 2020-07-11 12:36:41 UTC
(In reply to Samy Mahmoudi from comment #11)
> I should have reverted the introduction of that NLS option
Actually, I have already reverted the introduction of that NLS option (see the patch of comment 4).

Chris, could you review this patch?
Comment 13 Chris Hutchinson 2020-07-11 19:21:48 UTC
(In reply to Samy Mahmoudi from comment #12)
Would love to, and thanks for your time on this.
I'll be out today. But can get to it tomorrow.

Thanks again, Samy.

--Chris
Comment 14 Chris Hutchinson 2020-07-13 21:49:46 UTC
OK I had a chance to check out the diff you
submitted, Samy.
I'm afraid the (port) revision you're working
against is too old, and won't apply.
The current revision is @ 538818 / 2020-06-14
whereas yours is @ 492858

Looking at the differences. I think the current
revision should work fine -- WFM. :-)

Please try building against the current revision,
and tell me if you still have any problems. As I
said, I don't see any here. But it's important to
know if it still doesn't work for you.

Thanks for all your time, and efforts, Samy! :-)

--Chris