Re: NEW: godot - a 2D and 3D game engine and game development framework

[Stuart Henderson]

On 2018/04/26 18:00, Thomas Frohwein wrote:
> Thanks Stuart for identifying the problem with zstd and pointing me in
> in the right direction. I added a patch that reverts upstream's commit
> from October 26, 2017 that introduces the long-range matching which
> uses experimental/private APIs of zstd. Those APIs are not (yet?)
> exposed publicly in stable releases of zstd (see github issue #17374
> that Stuart pointed out to me).

These changes are all good and I didn't have any other concerns, OK
sthen@ if somebody would like to import.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Thomas Frohwein]

Thanks Stuart for identifying the problem with zstd and pointing me in
in the right direction. I added a patch that reverts upstream's commit
from October 26, 2017 that introduces the long-range matching which
uses experimental/private APIs of zstd. Those APIs are not (yet?)
exposed publicly in stable releases of zstd (see github issue #17374
that Stuart pointed out to me).

On Mon, Apr 23, 2018 at 09:29:51AM +0100, Stuart Henderson wrote:

> SUBST_CMD in this case. But however it's done, it should use PREFIX
> ("files from this port") not LOCALBASE ("already installed files").

Sure, I changed it to PREFIX.

> 
> It ought to honour CC/CXX from the environment but life's too short and
> the benefit is too little to be worth wrangling the stupid build tool
> for this. :)

Found SCONS flags that can set the proper CC/CXX. Same for CFLAGS, CXXFLAGS,
and LINKFLAGS/LDFLAGS.

> 
> The main thing I don't like about this is the .if after including bsd.port.mk,

The whole spiel with PROPERTIES and use_llvm isn't needed anymore after
setting CC/CXX.

Besides zstd, I disabled all the other built-in dependencies that I could.

Ran the 3D Martinique demo again to confirm it still works.
Updated version attached.


godot.tgz
Description: Binary data

Re: NEW: godot - a 2D and 3D game engine and game development framework

[tfrohw...@fastmail.com]

I agree. I'm working on fixing zstd - not as straightforward as I hoped, need a 
few more days I think.

On April 26, 2018 3:18:31 PM UTC, Stuart Henderson  wrote:
>IMHO/IME it's a waste of time trying to force scons into handling
>niceties, it's tricky enough getting the damn thing to build correctly
>in the first place.
>
>If you have a version with zstd fixed let's get it in and move on?
>
>On 2018/04/26 07:41, tfrohwein wrote:
>> Hi Brian,
>> 
>> These are the key points regarding scons:
>> 
>> > On 04/22/18 18:29, tfrohwein wrote:
>> > > > > >
>http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
>> > > > > > says "Python 2.7+ (Python 3 only supported as of SCons
>3.0)", our
>> > > > > > devel/scons is at 2.5.1, so you should set MODPY_VERSION
>accordingly.
>> > > > > scons does use python2.7 during the build. Would it make
>sense to rather add
>> > > > > this to the devel/scons module? (cc'ing Maintainer)
>> > > > > It's only used a build time.
>> > > > This might be because Python 3 is not installed on your system.
>> > > python3 *is* installed on my system.
>> > > 
>> > > > Explicitly setting the required version makes intention clear
>and avoids
>> > > > errors when building with autodetected versions.
>> > > > 
>> > > > If devel/scons<=2.5.1 is limited to Python 2 this should
>obviously be
>> > > > set there instead of every port using it.
>> > > Just going by existing ports, of 12 using scons module, only one
>sets
>> > > MODPY_VERSION (databases/mongodb). Here the list:
>> > > 
>> > > audio/hydrogen
>> > > databases/mongodb
>> > > emulators/fceux
>> > > games/boswars
>> > > games/dangerdeep
>> > > games/dxx-rebirth
>> > > games/pingus
>> > > graphics/mapnik
>> > > multimedia/ffmpeg2theora
>> > > net/serf
>> > > x11/gaia
>> > > x11/xsettingsd
>> > > 
>> > > While I acknowledge that pre-existing practice doesn't equal best
>approach,
>> > > whatever *would* break with the godot draft *should* already have
>broken the
>> > > 11 scons ports above that also don't set MODPY_VERSION. The fact
>that there
>> > > don't seem to be such reports indicates to me that this might
>ultimately be a
>> > > non-issue.
>> > > 
>> > > I think this should be in the discussion of the scons port, not
>this port. I'm
>> > > happy to adjust my ports if needed.
>> 
>> 1. Do ports using MODULE devel/scons need MODPY_VERSION to be set?
>(not current
>>practice based on above review)
>> 2. If so, would adding MODPY_VERSION to the scons module be a
>possibility?
>> 
>> > > > > > scons has full support for out-of-tree builds and ports as
>big as Godot
>> > > > > > will benefit from it, can you look into enabling
>SEPARATE_BUILD? See
>> > > > > > http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .
>> > > > > Enabling SEPARATE_BUILD alone doesn't achieve anything and
>the binary is still
>> > > > > built in WRKSRC.
>> > > > Yes, I noticed that.
>> > > > 
>> > > > > thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
>> > > > > thfr@e5570:/usr/ports$
>> > > > > 
>> > > > > There isn't a single example of using scons' variant
>directory tree in our
>> > > > > ports tree and the use is far from intuitive.
>> > > > > 
>> > > > > The example in your link uses a modification to a single
>SConscript file to
>> > > > > achieve this. godot doesn't have an SConscript file, but
>several SCsub files.
>> > > > > If someone more familiar with scons knows how to set this up
>with variant_dir
>> > > > > (including platform names in the build directory names)
>scenario I'd be happy
>> > > > > to test.
>> 
>> 3. Do you know of a way setting separate build directory with scons?
>The above
>>link describes a way with variant_dir, but this port has several
>SCsub
>>files, so this is at best trickier and neither of kn@ and me knows
>scons
>>well enough to set this up correctly. There are no examples of
>variant_dir
>>use in the ports tree...
>> 
>> > Scons needs an update too, version 3 was released some time ago. I
>couldn't
>> > get all the scons ports to build with the new version though and
>haven't had
>> > time to track things down. But I haven't been too worried since no
>one has
>> > proposed a port that requires the new scons...
>> 
>> This one also doesn't require version 3, so I don't think the update
>is a
>> pressing issue.
>> 

-- 
tfrohw...@fastmail.com


Other (more secure) messaging options:
t...@protonmail.com
t...@bitmessage.ch
bm-2ct3tfztzmp7g7wikr1t1fiosboc8wo...@bitmessage.ch
PGP Public Key:
https://pgp.mit.edu/pks/lookup?op=get=0xE1A22D58D20C6D22

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Stuart Henderson]

IMHO/IME it's a waste of time trying to force scons into handling
niceties, it's tricky enough getting the damn thing to build correctly
in the first place.

If you have a version with zstd fixed let's get it in and move on?

On 2018/04/26 07:41, tfrohwein wrote:
> Hi Brian,
> 
> These are the key points regarding scons:
> 
> > On 04/22/18 18:29, tfrohwein wrote:
> > > > > > http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
> > > > > > says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
> > > > > > devel/scons is at 2.5.1, so you should set MODPY_VERSION 
> > > > > > accordingly.
> > > > > scons does use python2.7 during the build. Would it make sense to 
> > > > > rather add
> > > > > this to the devel/scons module? (cc'ing Maintainer)
> > > > > It's only used a build time.
> > > > This might be because Python 3 is not installed on your system.
> > > python3 *is* installed on my system.
> > > 
> > > > Explicitly setting the required version makes intention clear and avoids
> > > > errors when building with autodetected versions.
> > > > 
> > > > If devel/scons<=2.5.1 is limited to Python 2 this should obviously be
> > > > set there instead of every port using it.
> > > Just going by existing ports, of 12 using scons module, only one sets
> > > MODPY_VERSION (databases/mongodb). Here the list:
> > > 
> > > audio/hydrogen
> > > databases/mongodb
> > > emulators/fceux
> > > games/boswars
> > > games/dangerdeep
> > > games/dxx-rebirth
> > > games/pingus
> > > graphics/mapnik
> > > multimedia/ffmpeg2theora
> > > net/serf
> > > x11/gaia
> > > x11/xsettingsd
> > > 
> > > While I acknowledge that pre-existing practice doesn't equal best 
> > > approach,
> > > whatever *would* break with the godot draft *should* already have broken 
> > > the
> > > 11 scons ports above that also don't set MODPY_VERSION. The fact that 
> > > there
> > > don't seem to be such reports indicates to me that this might ultimately 
> > > be a
> > > non-issue.
> > > 
> > > I think this should be in the discussion of the scons port, not this 
> > > port. I'm
> > > happy to adjust my ports if needed.
> 
> 1. Do ports using MODULE devel/scons need MODPY_VERSION to be set? (not 
> current
>practice based on above review)
> 2. If so, would adding MODPY_VERSION to the scons module be a possibility?
> 
> > > > > > scons has full support for out-of-tree builds and ports as big as 
> > > > > > Godot
> > > > > > will benefit from it, can you look into enabling SEPARATE_BUILD? See
> > > > > > http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .
> > > > > Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary 
> > > > > is still
> > > > > built in WRKSRC.
> > > > Yes, I noticed that.
> > > > 
> > > > > thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
> > > > > thfr@e5570:/usr/ports$
> > > > > 
> > > > > There isn't a single example of using scons' variant directory tree 
> > > > > in our
> > > > > ports tree and the use is far from intuitive.
> > > > > 
> > > > > The example in your link uses a modification to a single SConscript 
> > > > > file to
> > > > > achieve this. godot doesn't have an SConscript file, but several 
> > > > > SCsub files.
> > > > > If someone more familiar with scons knows how to set this up with 
> > > > > variant_dir
> > > > > (including platform names in the build directory names) scenario I'd 
> > > > > be happy
> > > > > to test.
> 
> 3. Do you know of a way setting separate build directory with scons? The above
>link describes a way with variant_dir, but this port has several SCsub
>files, so this is at best trickier and neither of kn@ and me knows scons
>well enough to set this up correctly. There are no examples of variant_dir
>use in the ports tree...
> 
> > Scons needs an update too, version 3 was released some time ago. I couldn't
> > get all the scons ports to build with the new version though and haven't had
> > time to track things down. But I haven't been too worried since no one has
> > proposed a port that requires the new scons...
> 
> This one also doesn't require version 3, so I don't think the update is a
> pressing issue.
> 

Re: NEW: godot - a 2D and 3D game engine and game development framework

[tfrohwein]

Hi Brian,

These are the key points regarding scons:

> On 04/22/18 18:29, tfrohwein wrote:
> > > > > http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
> > > > > says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
> > > > > devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.
> > > > scons does use python2.7 during the build. Would it make sense to 
> > > > rather add
> > > > this to the devel/scons module? (cc'ing Maintainer)
> > > > It's only used a build time.
> > > This might be because Python 3 is not installed on your system.
> > python3 *is* installed on my system.
> > 
> > > Explicitly setting the required version makes intention clear and avoids
> > > errors when building with autodetected versions.
> > > 
> > > If devel/scons<=2.5.1 is limited to Python 2 this should obviously be
> > > set there instead of every port using it.
> > Just going by existing ports, of 12 using scons module, only one sets
> > MODPY_VERSION (databases/mongodb). Here the list:
> > 
> > audio/hydrogen
> > databases/mongodb
> > emulators/fceux
> > games/boswars
> > games/dangerdeep
> > games/dxx-rebirth
> > games/pingus
> > graphics/mapnik
> > multimedia/ffmpeg2theora
> > net/serf
> > x11/gaia
> > x11/xsettingsd
> > 
> > While I acknowledge that pre-existing practice doesn't equal best approach,
> > whatever *would* break with the godot draft *should* already have broken the
> > 11 scons ports above that also don't set MODPY_VERSION. The fact that there
> > don't seem to be such reports indicates to me that this might ultimately be 
> > a
> > non-issue.
> > 
> > I think this should be in the discussion of the scons port, not this port. 
> > I'm
> > happy to adjust my ports if needed.

1. Do ports using MODULE devel/scons need MODPY_VERSION to be set? (not current
   practice based on above review)
2. If so, would adding MODPY_VERSION to the scons module be a possibility?

> > > > > scons has full support for out-of-tree builds and ports as big as 
> > > > > Godot
> > > > > will benefit from it, can you look into enabling SEPARATE_BUILD? See
> > > > > http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .
> > > > Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary 
> > > > is still
> > > > built in WRKSRC.
> > > Yes, I noticed that.
> > > 
> > > > thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
> > > > thfr@e5570:/usr/ports$
> > > > 
> > > > There isn't a single example of using scons' variant directory tree in 
> > > > our
> > > > ports tree and the use is far from intuitive.
> > > > 
> > > > The example in your link uses a modification to a single SConscript 
> > > > file to
> > > > achieve this. godot doesn't have an SConscript file, but several SCsub 
> > > > files.
> > > > If someone more familiar with scons knows how to set this up with 
> > > > variant_dir
> > > > (including platform names in the build directory names) scenario I'd be 
> > > > happy
> > > > to test.

3. Do you know of a way setting separate build directory with scons? The above
   link describes a way with variant_dir, but this port has several SCsub
   files, so this is at best trickier and neither of kn@ and me knows scons
   well enough to set this up correctly. There are no examples of variant_dir
   use in the ports tree...

> Scons needs an update too, version 3 was released some time ago. I couldn't
> get all the scons ports to build with the new version though and haven't had
> time to track things down. But I haven't been too worried since no one has
> proposed a port that requires the new scons...

This one also doesn't require version 3, so I don't think the update is a
pressing issue.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Brian Callahan]

On 04/22/18 18:29, tfrohwein wrote:

http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.

scons does use python2.7 during the build. Would it make sense to rather add
this to the devel/scons module? (cc'ing Maintainer)
It's only used a build time.

This might be because Python 3 is not installed on your system.

python3 *is* installed on my system.


Explicitly setting the required version makes intention clear and avoids
errors when building with autodetected versions.

If devel/scons<=2.5.1 is limited to Python 2 this should obviously be
set there instead of every port using it.

Just going by existing ports, of 12 using scons module, only one sets
MODPY_VERSION (databases/mongodb). Here the list:

audio/hydrogen
databases/mongodb
emulators/fceux
games/boswars
games/dangerdeep
games/dxx-rebirth
games/pingus
graphics/mapnik
multimedia/ffmpeg2theora
net/serf
x11/gaia
x11/xsettingsd

While I acknowledge that pre-existing practice doesn't equal best approach,
whatever *would* break with the godot draft *should* already have broken the
11 scons ports above that also don't set MODPY_VERSION. The fact that there
don't seem to be such reports indicates to me that this might ultimately be a
non-issue.

I think this should be in the discussion of the scons port, not this port. I'm
happy to adjust my ports if needed.


scons has full support for out-of-tree builds and ports as big as Godot
will benefit from it, can you look into enabling SEPARATE_BUILD? See
http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .

Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary is still
built in WRKSRC.

Yes, I noticed that.


thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
thfr@e5570:/usr/ports$

There isn't a single example of using scons' variant directory tree in our
ports tree and the use is far from intuitive.

The example in your link uses a modification to a single SConscript file to
achieve this. godot doesn't have an SConscript file, but several SCsub files.
If someone more familiar with scons knows how to set this up with variant_dir
(including platform names in the build directory names) scenario I'd be happy
to test.

Unfortunately, I'm completely unfamiliar with scons, too.

Brian, maybe you can help out?

Either ways, SEPARATE_BUILD shouldn't block the import of Godot once
the port is ready. We can still work on that later on.

Agree.



Sorry I'm late to this party, though now I'm unsure what I'm supposed to 
be helping out with?
Scons needs an update too, version 3 was released some time ago. I 
couldn't get all the scons ports to build with the new version though 
and haven't had time to track things down. But I haven't been too 
worried since no one has proposed a port that requires the new scons...


~Brian

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Stuart Henderson]

There's a problem if zstd is installed, this happens when it builds
its internal copy:


clang -o thirdparty/zstd/compress/zstd_compress.x11.opt.tools.64.llvm.o -c -g1 
-O2 -ffast-math -DDEBUG_ENABLED -O2 -pipe -pipe -w -DZSTD_STATIC_LINKING_ONLY 
-DFREETYPE_ENABLED -DRECAST_ENABLED -DSVG_ENABLED -DTYPED_METHOD_BIND 
-DTOUCH_ENABLED -DPULSEAUDIO_ENABLED -DX11_ENABLED -DUNIX_ENABLED 
-DOPENGL_ENABLED -DGLES_ENABLED -DGLES_OVER_GL -DPTRCALL_ENABLED 
-DTOOLS_ENABLED -DGDSCRIPT_ENABLED -DMINIZIP_ENABLED -DXML_ENABLED 
-DGLAD_ENABLED -DGLES_OVER_GL -D_REENTRANT -Icore -Icore/math -Ieditor 
-Idrivers -I. -I/usr/X11R6/include -I/usr/local/include 
-I/usr/X11R6/include/freetype2 -I/usr/local/include/libpng16 
-I/usr/local/include/opus -Iplatform/x11 -Ithirdparty/zstd 
-Ithirdparty/zstd/common -Ithirdparty/glad -Ithirdparty/recastnavigation/Recast 
-Ithirdparty/recastnavigation/Recast/Include -Ithirdparty/nanosvg 
thirdparty/zstd/compress/zstd_compress.c
In file included from thirdparty/zstd/compress/zstd_compress.c:29:
thirdparty/zstd/compress/zstd_compress_internal.h:46:5: error: unknown type 
name 'ZSTD_dictMode_e'
ZSTD_dictMode_e dictMode;
^
thirdparty/zstd/compress/zstd_compress_internal.h:449:37: error: unknown type 
name 'ZSTD_dictMode_e'
ZSTD_dictMode_e dictMode,
^
thirdparty/zstd/compress/zstd_compress.c:215:8: error: conflicting types for 
'ZSTD_initCCtxParams'
size_t ZSTD_initCCtxParams(ZSTD_CCtx_params* cctxParams, int compressionLevel) {
   ^
thirdparty/zstd/compress/zstd_compress.c:212:12: note: previous implicit 
declaration is here
return ZSTD_initCCtxParams(params, ZSTD_CLEVEL_DEFAULT);
   ^
thirdparty/zstd/compress/zstd_compress.c:283:10: error: use of undeclared 
identifier 'ZSTD_p_nbThreads'; did you mean 'ZSTD_p_nbWorkers'?
case ZSTD_p_nbThreads:
 ^~~~
 ZSTD_p_nbWorkers
/usr/local/include/zstd.h:1031:5: note: 'ZSTD_p_nbWorkers' declared here
ZSTD_p_nbWorkers=400,/* Select how many threads will be spawned to 
compress in parallel.
^
thirdparty/zstd/compress/zstd_compress.c:372:54: error: use of undeclared 
identifier 'ZSTD_TARGETLENGTH_MAX'
CLAMPCHECK(value, ZSTD_TARGETLENGTH_MIN, ZSTD_TARGETLENGTH_MAX);
 ^
thirdparty/zstd/compress/zstd_compress.c:406:10: error: use of undeclared 
identifier 'ZSTD_p_nbThreads'; did you mean 'ZSTD_p_nbWorkers'?
case ZSTD_p_nbThreads :
 ^~~~
 ZSTD_p_nbWorkers
/usr/local/include/zstd.h:1031:5: note: 'ZSTD_p_nbWorkers' declared here
ZSTD_p_nbWorkers=400,/* Select how many threads will be spawned to 
compress in parallel.
^
thirdparty/zstd/compress/zstd_compress.c:495:47: error: unknown type name 
'ZSTD_dictMode_e'
ZSTD_dictLoadMethod_e dictLoadMethod, ZSTD_dictMode_e dictMode)
  ^
thirdparty/zstd/compress/zstd_compress.c:522:51: error: use of undeclared 
identifier 'ZSTD_dm_auto'; did you mean 'ZSTD_dct_auto'?
cctx, dict, dictSize, ZSTD_dlm_byRef, ZSTD_dm_auto);
  ^~~~
  ZSTD_dct_auto
/usr/local/include/zstd.h:435:5: note: 'ZSTD_dct_auto' declared here
ZSTD_dct_auto=0,  /* dictionary is "full" when starting with 
ZSTD_MAGIC_DICTIONARY, otherwise it is "rawContent" */
^
thirdparty/zstd/compress/zstd_compress.c:528:52: error: use of undeclared 
identifier 'ZSTD_dm_auto'; did you mean 'ZSTD_dct_auto'?
cctx, dict, dictSize, ZSTD_dlm_byCopy, ZSTD_dm_auto);
   ^~~~
   ZSTD_dct_auto
/usr/local/include/zstd.h:435:5: note: 'ZSTD_dct_auto' declared here
ZSTD_dct_auto=0,  /* dictionary is "full" when starting with 
ZSTD_MAGIC_DICTIONARY, otherwise it is "rawContent" */
^
thirdparty/zstd/compress/zstd_compress.c:542:67: error: use of undeclared 
identifier 'ZSTD_dm_rawContent'; did you mean 'ZSTD_dct_rawContent'?
return ZSTD_CCtx_refPrefix_advanced(cctx, prefix, prefixSize, 
ZSTD_dm_rawContent);
  
^~
  
ZSTD_dct_rawContent
/usr/local/include/zstd.h:436:5: note: 'ZSTD_dct_rawContent' declared here
ZSTD_dct_rawContent,  /* ensures dictionary is always loaded as rawContent, 
even if it starts with ZSTD_MAGIC_DICTIONARY */
^
thirdparty/zstd/compress/zstd_compress.c:546:65: error: unknown type name 
'ZSTD_dictMode_e'
ZSTD_CCtx* cctx, const void* prefix, size_t prefixSize, ZSTD_dictMode_e 
dictMode)
^
thirdparty/zstd/compress/zstd_compress.c:580:61: error: use of undeclared 
identifier 'ZSTD_TARGETLENGTH_MAX'

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Stuart Henderson]

On 2018/04/21 12:01, tfrohwein wrote:
> On Tue, Apr 10, 2018 at 09:20:37PM -0700, Thomas Frohwein wrote:
> 
> ping
> 
> > Hi,
> > 
> > Please find attached a port of Godot. Godot, "The Game Engine You Waited 
> > For"
> > (semi-official subtitle), is a professional-grade game development framework
> > and game engine, capable of designing 2D, as well as 3D games. It is most
> > commonly compared to Unity. It features its own GDScript language for the
> > scripting aspect of the development, but also offers interfaces for C++ or
> > Visual Script (using blocks and connections).
> > 
> > It works well on testing with a tutorial 2D game, as well as when running 
> > the
> > 3D demo 'Martinique' (https://github.com/w84death/Martinique).
> > 
> > A few notes on the port:
> > - C# support: this is advertised by upstream (done via mono), but FreeBSD's
> >   port describes it as unstable. I left it out for now; may add it in future
> >   update.
> > - This may be common knowledge, but it took me a while to find out that
> >   pulseaudio requires messagebus to be activated (x11/dbus -> rcctl enable
> >   messagebus).
> > - The previously described "crashy" state (on the openbsd-wip repo) was 
> > likely
> >   due to the failing to find its own path when entering the main interface. 
> > The
> >   post-extract target fixes that with a hard-coded location of the binary. I
> >   have not observed any unstability or crashing when using Godot.
> > - In order to build with clang, it needs the use_llvm flag. I moved this 
> > into a
> >   .if ${PROPERTIES:Mclang} to give non-clang arches a chance.
> > 
> > This is based on prior work by bentley@.
> 
> 

The main thing I don't like about this is the .if after including bsd.port.mk,
PROPERTIES are setup from bsd.port.arch.mk so there's no need for the whole 
thing.
e.g.

--snip
.include 

.if ${PROPERTIES:Mclang}
MODSCONS_FLAGS +=   use_llvm=yes
.endif

.include 
--snip

For the path-finding, I do think in this case a patch is better because
if upstream change anything in this area the sed will silently no longer
apply so it won't be noticed until runtime. So I would go for patch and
SUBST_CMD in this case. But however it's done, it should use PREFIX
("files from this port") not LOCALBASE ("already installed files").

It ought to honour CC/CXX from the environment but life's too short and
the benefit is too little to be worth wrangling the stupid build tool
for this. :)

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Stuart Henderson]

On 2018/04/21 22:20, Klemens Nanni wrote:
> Can you please patch drivers/unix/os_unix.cpp and SUBST_CMD it in
> post-patch? sed(1) might be the tool if you cannot avoid massive editing
> and want to avoid tons of patches for that, but in general I'd like to
> stop editing sources in place.

SUBST_CMD is exactly editing in place. Take it on a case by case basis.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[tfrohwein]

> > > http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
> > > says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
> > > devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.
> > 
> > scons does use python2.7 during the build. Would it make sense to rather add
> > this to the devel/scons module? (cc'ing Maintainer)
> > It's only used a build time.
> This might be because Python 3 is not installed on your system.

python3 *is* installed on my system.

> Explicitly setting the required version makes intention clear and avoids
> errors when building with autodetected versions.
> 
> If devel/scons<=2.5.1 is limited to Python 2 this should obviously be
> set there instead of every port using it.

Just going by existing ports, of 12 using scons module, only one sets
MODPY_VERSION (databases/mongodb). Here the list:

audio/hydrogen
databases/mongodb
emulators/fceux
games/boswars
games/dangerdeep
games/dxx-rebirth
games/pingus
graphics/mapnik
multimedia/ffmpeg2theora
net/serf
x11/gaia
x11/xsettingsd

While I acknowledge that pre-existing practice doesn't equal best approach,
whatever *would* break with the godot draft *should* already have broken the
11 scons ports above that also don't set MODPY_VERSION. The fact that there
don't seem to be such reports indicates to me that this might ultimately be a
non-issue.

I think this should be in the discussion of the scons port, not this port. I'm
happy to adjust my ports if needed.

> 
> > > scons has full support for out-of-tree builds and ports as big as Godot
> > > will benefit from it, can you look into enabling SEPARATE_BUILD? See
> > > http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .
> > 
> > Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary is 
> > still
> > built in WRKSRC.
> Yes, I noticed that.
> 
> > thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
> > thfr@e5570:/usr/ports$
> > 
> > There isn't a single example of using scons' variant directory tree in our
> > ports tree and the use is far from intuitive.
> > 
> > The example in your link uses a modification to a single SConscript file to
> > achieve this. godot doesn't have an SConscript file, but several SCsub 
> > files.
> > If someone more familiar with scons knows how to set this up with 
> > variant_dir
> > (including platform names in the build directory names) scenario I'd be 
> > happy
> > to test.
> Unfortunately, I'm completely unfamiliar with scons, too.
> 
> Brian, maybe you can help out?
> 
> Either ways, SEPARATE_BUILD shouldn't block the import of Godot once
> the port is ready. We can still work on that later on.

Agree.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Klemens Nanni]

On Sun, Apr 22, 2018 at 09:29:28AM -0700, tfrohwein wrote:
> > Have you asked upstream to provide stable release assets?
> 
> https://github.com/godotengine/godot/issues/18347
> 
> > I couldn't find an issue or pull request referencing the clang 6 fixes
> > in patches/patch-scene_gui_rich_text_label_cpp, current HEAD doesn't
> > have them either. Can you bring up this issue upstream as well?
> 
> https://github.com/godotengine/godot/pull/18348
Thanks.

> > Can you please patch drivers/unix/os_unix.cpp and SUBST_CMD it in
> > post-patch? sed(1) might be the tool if you cannot avoid massive editing
> > and want to avoid tons of patches for that, but in general I'd like to
> > stop editing sources in place.
> 
> Done, and works. sed is still used a lot in the ports tree. I guess your plan
> is to weed this out over time?
There's no strict plan, but patching is simply cleaner here imho.

> > http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
> > says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
> > devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.
> 
> scons does use python2.7 during the build. Would it make sense to rather add
> this to the devel/scons module? (cc'ing Maintainer)
> It's only used a build time.
This might be because Python 3 is not installed on your system.
Explicitly setting the required version makes intention clear and avoids
errors when building with autodetected versions.

If devel/scons<=2.5.1 is limited to Python 2 this should obviously be
set there instead of every port using it.

> > scons has full support for out-of-tree builds and ports as big as Godot
> > will benefit from it, can you look into enabling SEPARATE_BUILD? See
> > http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .
> 
> Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary is still
> built in WRKSRC.
Yes, I noticed that.

> thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
> thfr@e5570:/usr/ports$
> 
> There isn't a single example of using scons' variant directory tree in our
> ports tree and the use is far from intuitive.
> 
> The example in your link uses a modification to a single SConscript file to
> achieve this. godot doesn't have an SConscript file, but several SCsub files.
> If someone more familiar with scons knows how to set this up with variant_dir
> (including platform names in the build directory names) scenario I'd be happy
> to test.
Unfortunately, I'm completely unfamiliar with scons, too.

Brian, maybe you can help out?

Either ways, SEPARATE_BUILD shouldn't block the import of Godot once
the port is ready. We can still work on that later on.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[tfrohwein]

Thanks for the thorough review!

> Have you asked upstream to provide stable release assets?

https://github.com/godotengine/godot/issues/18347

> I couldn't find an issue or pull request referencing the clang 6 fixes
> in patches/patch-scene_gui_rich_text_label_cpp, current HEAD doesn't
> have them either. Can you bring up this issue upstream as well?

https://github.com/godotengine/godot/pull/18348

> Can you please patch drivers/unix/os_unix.cpp and SUBST_CMD it in
> post-patch? sed(1) might be the tool if you cannot avoid massive editing
> and want to avoid tons of patches for that, but in general I'd like to
> stop editing sources in place.

Done, and works. sed is still used a lot in the ports tree. I guess your plan
is to weed this out over time?

> http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
> says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
> devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.

scons does use python2.7 during the build. Would it make sense to rather add
this to the devel/scons module? (cc'ing Maintainer)
It's only used a build time.

> scons has full support for out-of-tree builds and ports as big as Godot
> will benefit from it, can you look into enabling SEPARATE_BUILD? See
> http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .

Enabling SEPARATE_BUILD alone doesn't achieve anything and the binary is still
built in WRKSRC.

thfr@e5570:/usr/ports$ fgrep -iR variant_dir *
thfr@e5570:/usr/ports$

There isn't a single example of using scons' variant directory tree in our
ports tree and the use is far from intuitive.

The example in your link uses a modification to a single SConscript file to
achieve this. godot doesn't have an SConscript file, but several SCsub files.
If someone more familiar with scons knows how to set this up with variant_dir
(including platform names in the build directory names) scenario I'd be happy
to test.

Updated tarball attached. Tested this one briefly without noticing any issues.


godot.tgz
Description: Binary data

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Klemens Nanni]

On Sat, Apr 21, 2018 at 10:20:53PM +0200, Klemens Nanni wrote:
> CC, CFLAGS and DEBUG need handling, they're currently ignored.
Error on my part, please ignore that.

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Klemens Nanni]

On Tue, Apr 10, 2018 at 09:20:37PM -0700, Thomas Frohwein wrote:
> Please find attached a port of Godot. Godot, "The Game Engine You Waited For"
> (semi-official subtitle), is a professional-grade game development framework
> and game engine, capable of designing 2D, as well as 3D games. It is most
> commonly compared to Unity. It features its own GDScript language for the
> scripting aspect of the development, but also offers interfaces for C++ or
> Visual Script (using blocks and connections).
Have you asked upstream to provide stable release assets?

I couldn't find an issue or pull request referencing the clang 6 fixes
in patches/patch-scene_gui_rich_text_label_cpp, current HEAD doesn't
have them either. Can you bring up this issue upstream as well?

> It works well on testing with a tutorial 2D game, as well as when running the
> 3D demo 'Martinique' (https://github.com/w84death/Martinique).
> 
> A few notes on the port:
> - C# support: this is advertised by upstream (done via mono), but FreeBSD's
>   port describes it as unstable. I left it out for now; may add it in future
>   update.
Sounds reasonable.

> - The previously described "crashy" state (on the openbsd-wip repo) was likely
>   due to the failing to find its own path when entering the main interface. 
> The
>   post-extract target fixes that with a hard-coded location of the binary. I
>   have not observed any unstability or crashing when using Godot.
Can you please patch drivers/unix/os_unix.cpp and SUBST_CMD it in
post-patch? sed(1) might be the tool if you cannot avoid massive editing
and want to avoid tons of patches for that, but in general I'd like to
stop editing sources in place.

> - In order to build with clang, it needs the use_llvm flag. I moved this into 
> a
>   .if ${PROPERTIES:Mclang} to give non-clang arches a chance.
Yup.

http://docs.godotengine.org/en/latest/development/compiling/compiling_for_x11.html
says "Python 2.7+ (Python 3 only supported as of SCons 3.0)", our
devel/scons is at 2.5.1, so you should set MODPY_VERSION accordingly.

CC, CFLAGS and DEBUG need handling, they're currently ignored.

scons has full support for out-of-tree builds and ports as big as Godot
will benefit from it, can you look into enabling SEPARATE_BUILD? See
http://www.scons.org/doc/2.5.0/HTML/scons-user/ch15.html .

Re: NEW: godot - a 2D and 3D game engine and game development framework

[tfrohwein]

On Tue, Apr 10, 2018 at 09:20:37PM -0700, Thomas Frohwein wrote:

ping

> Hi,
> 
> Please find attached a port of Godot. Godot, "The Game Engine You Waited For"
> (semi-official subtitle), is a professional-grade game development framework
> and game engine, capable of designing 2D, as well as 3D games. It is most
> commonly compared to Unity. It features its own GDScript language for the
> scripting aspect of the development, but also offers interfaces for C++ or
> Visual Script (using blocks and connections).
> 
> It works well on testing with a tutorial 2D game, as well as when running the
> 3D demo 'Martinique' (https://github.com/w84death/Martinique).
> 
> A few notes on the port:
> - C# support: this is advertised by upstream (done via mono), but FreeBSD's
>   port describes it as unstable. I left it out for now; may add it in future
>   update.
> - This may be common knowledge, but it took me a while to find out that
>   pulseaudio requires messagebus to be activated (x11/dbus -> rcctl enable
>   messagebus).
> - The previously described "crashy" state (on the openbsd-wip repo) was likely
>   due to the failing to find its own path when entering the main interface. 
> The
>   post-extract target fixes that with a hard-coded location of the binary. I
>   have not observed any unstability or crashing when using Godot.
> - In order to build with clang, it needs the use_llvm flag. I moved this into 
> a
>   .if ${PROPERTIES:Mclang} to give non-clang arches a chance.
> 
> This is based on prior work by bentley@.




godot.tgz
Description: Binary data

Re: NEW: godot - a 2D and 3D game engine and game development framework

[Christian Ruesch]

I have waited a long time for a working port of Godot.  Godot runs on
my Thinkpad t460p on OpenBSD -current amd64 without any problems.  I
hope Godot will be included in the ports tree and made available as a
package.

Best regards,
Christian