Add port for liblightgrep

[jessekornblum@…]

liblightgrep is a library for searching data using regular expressions as defined in Unicode Technical Standard #18. There are lots of details, including a handy cheat sheet, at the project's homepage, ​http://www.lightboxtechnologies.com/lightgrep-engine.

I am willing to be the maintainer of this port.

[cooljeanius (Eric Gallager)]

First thing I notice: you should probably be using compiler.blacklist and compiler.whitelist instead of manually setting CC and CXX in the build environment.

[cooljeanius (Eric Gallager)]

Cc Me!

[jessekornblum@…]

Can you please point me to the documentation for specifying the compiler to use? I'm having trouble finding it. The library requires gcc 4.6 or later. How do I force the configure command to use the latest version of gcc/g++ above 4.6?

thanks!

[larryv (Lawrence Velázquez)]

Replying to jessekornblum@…:

Can you please point me to the documentation for specifying the compiler to use? I'm having trouble finding it.

There… uh… really isn’t any. There are a couple of wiki pages:

• PortfileRecipes#compiler
• UsingTheRightCompiler

The recipe is outdated; MacPorts 2.2 automatically adds the necessary dependencies for compilers.

The library requires gcc 4.6 or later. How do I force the configure command to use the latest version of gcc/g++ above 4.6?

Remove the build dependency on port:gcc48 and add this:

compiler.whitelist  macports-gcc-4.8 \
                    macports-gcc-4.7 \
                    macports-gcc-4.6

configure.args      CC=${configure.cc} \
                    CXX=${configure.cxx}

[larryv (Lawrence Velázquez)]

Also disable the universal variant, since you’re using FSF GCC:

universal_variant   no

(Unless you feel like adding the muniversal-1.0 PortGroup and hacking together a universal build manually.)

[jessekornblum@…]

Updated with feedback

[jessekornblum@…]

I have replaced the Portfile with the compiler whitelist. Thank you!

[ryandesign (Ryan Carsten Schmidt)]

I'm always suspicious of ports claiming to require recent gcc. Often they really don't; often clang would be sufficient as well, and that's what we'd prefer to use. I tried using llvm-gcc-4.2 and got:

checking whether /usr/bin/llvm-g++-4.2 supports C++11 features by default... no
checking whether /usr/bin/llvm-g++-4.2 supports C++11 features with -std=c++11... no
checking whether /usr/bin/llvm-g++-4.2 supports C++11 features with -std=c++0x... no
configure: error: *** A compiler with support for C++11 language features is required.

A-ha! So C++11 is the actual requirement. Well recent clang supports that. Actually "C++11" is a collection of various features, and different features became available in different versions of clang; there's a ​table for that on the clang website. We should figure out which versions of clang can build this port, and blacklist earlier ones, along with other compilers that won't work, including llvm-gcc and Apple gcc. It built fine for me using clang from Xcode 4.6.3 ("Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)"), and also with MacPorts clang 3.1 and 3.2. It failed with 3.3 and 3.4; I filed an ​upstream bug report for that. It failed with 2.9 and 3.0. Still need to test older versions of Xcode clang.

---

There should be no need to manually specify the CC and CXX variables at configure time since MacPorts always does so anyway.

---

I noticed this message printed during the configure phase:

checking if bison is the parser generator... yes
-n bison version is... 
bison (GNU Bison) 2.7.12-4996

This errant "-n" indicates non-POSIX use of "echo -n" which should be replaced with "printf". The configure.ac file should be patched for this.

---

I noticed this configure output:

checking whether the Boost::System library is available... yes
./configure: line 17639: tac: command not found
sed: stdout: Broken pipe
./configure: line 17639: tac: command not found
checking whether the Boost::Thread library is available... yes

The "tac" command is not part of OS X but is provided by the coreutils port under the name "gtac". However, just changing "tac" to "gtac" in m4/ax_boost_system.m4 isn't enough to make things work; that file has other OS X incompatibilities. This was already reported and fixed ​here so we should apply that patch to the file. See also ​this upstream pull request which includes this and other fixes for FreeBSD (which are probably also useful for compatibility with the older version of bash on older versions of OS X).

---

I noticed this configure output:

configure: No path given for --with-icu, using icu-config from your PATH.

To avoid any confusion, I specified --with-icu=${prefix}/bin in configure.args.

---

The build failed with the universal variant because the CFLAGS ended up containing -arch x86_64 i386—the second -arch has been removed. This output from the configure script shows this was a deliberate (incorrect) act:

removing duplicate -arch from CFLAGS
removing duplicate -arch from CXXFLAGS

I have filed an ​upstream bug report about this. It's fixed by removing the three invocations of LG_UNIQ_FLAGS from configure.ac.

---

I canonicalized the homepage to avoid redirects by adding a slash to the end of it.

---

Looks like it uses the boost static libraries, not the dynamic libraries, so boost should be a build dependency, not a library dependency.

---

The port should use the standard modeline and conform to it. That means using spaces instead of tabs.

---

I've attached a revised Portfile and patches making the above changes. It builds for me on OS X 10.8.4 with Xcode 4.6.3, but I'm having trouble building it on earlier OS X. I'll try again there after my older machines have finished building some more compilers to test with.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

I noticed this configure output:

checking whether the Boost::System library is available... yes
./configure: line 17639: tac: command not found
sed: stdout: Broken pipe
./configure: line 17639: tac: command not found
checking whether the Boost::Thread library is available... yes

The "tac" command is not part of OS X but is provided by the coreutils port under the name "gtac". However, just changing "tac" to "gtac" in m4/ax_boost_system.m4 isn't enough to make things work; that file has other OS X incompatibilities. This was already reported and fixed ​here so we should apply that patch to the file.

Or we could just update autoconf-archive to the latest version (as per #39804), and then force liblightgrep to use the macro from the autoconf-archive package instead of its vendored-in version.

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

and then force liblightgrep to use the macro from the autoconf-archive package instead of its vendored-in version.

How does one do that?

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

Replying to egall@…:

and then force liblightgrep to use the macro from the autoconf-archive package instead of its vendored-in version.

How does one do that?

uh... let's see, there are multiple ways... but on second thought, they'd all probably be more trouble than they're worth though:

• make aclocal ignore the m4 directory by removing AC_CONFIG_MACRO_DIR([m4]) from configure.ac and ACLOCAL_AMFLAGS = -I m4 from Makefile.am (probably a bad idea, as I'm pretty sure it does actually need to look in the m4 directory for the the macros from the lg_*.m4 files...)
• try setting some environment variables (might not work)
• instead of patching the offending file, just copy our version from ${prefix}/share/aclocal and have it overwrite the local version when copying. Although there's not really much difference from just patching it at that point...

(so anyways, never mind...)

[ryandesign (Ryan Carsten Schmidt)]

Port added in r141065. Many of the issues I mentioned above have been resolved upstream since then so the patches I had above are no longer needed.