Patch for premake 4.4 beta 5 from premake 4

[Sergei G]

I should've probably posted in here, but I have created yesterday issue in
official premake bug tracking system with reference to this thread.

https://bitbucket.org/premake/premake-dev/issue/241/freebsd-10-support-on-44-beta-5



On Wed, Jun 25, 2014 at 1:10 AM, Konstantin Tokarev <annulen at yandex.ru>
wrote:

> CC'ing premake developers.
>
> 24.06.2014, 18:09, "Vitaly Magerya" <vmagerya at gmail.com>:
> >  TL;DR: could a brave ports comitter apply an update for
> >  devel/premake4 at [1]? That would be much appreciated.
> >
> >  Redports logs for this update are at [2].
> >
> >  Note that redports for some reason doesn't invoke regression-test
> >  target today; probably a bug on their part.
> >
> >  On 2014-06-24 09:51, Sergei G wrote:
> >>   I had to update Premake 4 port (4.3) to 4.4 beta 5 on FreeBSD
> >>   10.0-RELEASE #0.
> >>
> >>   I included patch file with changes applied to Premake 4 port. The
> >>   changes consist of:
> >>
> >>   3 regression tests failed (it appears due to at least one missing
> patch
> >>   file):
> >  The main cause of these regressions is actually a very strange
> >  one (and you're right that those patches are what fixed it in
> >  the past). So, in one of it's routines premake tries to open
> >  '/etc/ld.so.conf'; it does so via Lua function 'io.open'. Now,
> >  FreeBSD doesn't have that file, and in theory 'io.open' should
> >  return 'nil', which should cause premake to skip this file. What
> >  actually happens is that 'io.open' returns some object that is
> >  neither nil, nor a proper file object. Premake thinks that 'io.open'
> >  succeeded, and tries to read from that non-nil, non-file object,
> >  which doesn't work.
> >
> >  Why doesn't 'io.open' return 'nil' here is a mystery to me. Maybe
> >  premake ships with buggy Lua sources. I don't know.
> >
> >  In any case, this problem is fixed in the patch at [1].
> >>   Once I installed premake I observed that it generated Makefile with
> gcc
> >>   in it, instead of clang. Should switch to clang be applied at premake
> or
> >>   Box2D project level?
> >  It appears that Premake only supports GCC for its "gmake" target.
> >
> >  It is possible to simply replace "gcc" with "clang" in the premake
> >  sources, and it will mostly work, but:
> >  1) it will not work for projects that use advanced options, since
> >      clang does not support, and in fact fails on some of the flags
> >      premake may pass to it ("-ffast-math" for example);
> >  2) makefiles generated on FreeBSD will fail on other platforms
> >      (not sure if premake promises them to work though).
> >
> >  The long-term solution for premake is to recognize "clang" as a
> >  valid compiler, and provide a set of flags it understands.
> >
> >  The short-term solution for programs that use premake is to either
> >  require GCC from ports, or to manually replace "gcc" with "clang"
> >  before building, patching out incompatible compiler flags, if any.
> >
> >  Note that Box2D v2.3.1 doesn't seem to use any flags that clang
> >  doesn't understand, so it is safe to change "gcc" into "cc", and
> >  "g++" into "c++" in the makefiles that premake generates for it.
> >
> >  [1] http://tx97.net/~magv/diff/premake-4.4.b5.diff
> >  [2] https://redports.org/buildarchive/20140624134401-54287/
> >  _______________________________________________
> >  freebsd-ports at freebsd.org mailing list
> >  http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> >  To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org
> "
>
> --
> Regards, Konstantin
>