[MacPorts] #40044: Add port for liblightgrep

[MacPorts]

#40044: Add port for liblightgrep
------------------------------+--------------------------------
  Reporter:  jessekornblum@…  |      Owner:  macports-tickets@…
      Type:  submission       |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:  2.2.0
Resolution:                   |   Keywords:
      Port:  liblightgrep     |
------------------------------+--------------------------------
Changes (by ryandesign@…):

 * cc: ryandesign@… (added)


Comment:

 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
 [http://clang.llvm.org/cxx_status.html 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 [https://github.com/jonstewart/liblightgrep/issues/4
 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
 [https://savannah.gnu.org/patch/?7839 here] so we should apply that patch
 to the file. See also [https://github.com/jonstewart/liblightgrep/pull/2
 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 [https://github.com/jonstewart/liblightgrep/issues/3
 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/40044#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X