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

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein
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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Christian Ruesch-3
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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
In reply to this post by Thomas Frohwein
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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Klemens Nanni-2
In reply to this post by Thomas Frohwein
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 .

Reply | Threaded
Open this post in threaded view
|

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

Klemens Nanni-2
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.

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
In reply to this post by Klemens Nanni-2
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 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Klemens Nanni-2
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.

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
> > > 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.

Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Klemens Nanni-2
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.

Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson
In reply to this post by Thomas Frohwein-2
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 <bsd.port.arch.mk>

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

.include <bsd.port.mk>
--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. :)

Reply | Threaded
Open this post in threaded view
|

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'
    CLAMPCHECK(cParams.targetLength, ZSTD_TARGETLENGTH_MIN, ZSTD_TARGETLENGTH_MAX);
                                                            ^
thirdparty/zstd/compress/zstd_compress.c:600:56: error: use of undeclared identifier 'ZSTD_TARGETLENGTH_MAX'
    CLAMP(cParams.targetLength, ZSTD_TARGETLENGTH_MIN, ZSTD_TARGETLENGTH_MAX);
                                                       ^
thirdparty/zstd/compress/zstd_compress.c:600:56: error: use of undeclared identifier 'ZSTD_TARGETLENGTH_MAX'
thirdparty/zstd/compress/zstd_compress.c:2050:46: error: unknown type name 'ZSTD_dictMode_e'
                                             ZSTD_dictMode_e dictMode)
                                             ^
thirdparty/zstd/compress/zstd_compress.c:2056:19: error: use of undeclared identifier 'ZSTD_dm_rawContent'; did you mean 'ZSTD_dct_rawContent'?
    if (dictMode==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:2060:25: error: use of undeclared identifier 'ZSTD_dm_auto'; did you mean 'ZSTD_dct_auto'?
        if (dictMode == 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:2064:25: error: use of undeclared identifier 'ZSTD_dm_fullDict'; did you mean 'ZSTD_dct_fullDict'?
        if (dictMode == ZSTD_dm_fullDict)
                        ^~~~~~~~~~~~~~~~
                        ZSTD_dct_fullDict
/usr/local/include/zstd.h:437:5: note: 'ZSTD_dct_fullDict' declared here
    ZSTD_dct_fullDict     /* refuses to load a dictionary if it does not respect Zstandard's specification */
    ^
thirdparty/zstd/compress/zstd_compress.c:2077:30: error: unknown type name 'ZSTD_dictMode_e'
                             ZSTD_dictMode_e dictMode,
                             ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
scons: *** [thirdparty/zstd/compress/zstd_compress.x11.opt.tools.64.llvm.o] Error 1
scons: building terminated because of errors.
*** Error 2 in . (/usr/ports/devel/scons/scons.port.mk:32 'do-build': @/usr/bin/env -i PORTSDIR="/usr/ports" LIBTOOL="/usr/bin/libtool"  PAT...)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2736 '/usr/obj/ports/godot-3.0.2/.build_done')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1938 '/usr/ports/packages/amd64/all/godot-3.0.2.tgz')

Reply | Threaded
Open this post in threaded view
|

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

Brian Callahan-3
In reply to this post by Thomas Frohwein-2

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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
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.

Reply | Threaded
Open this post in threaded view
|

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.
>

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
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 <[hidden email]> 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.
>>

--
[hidden email]


Other (more secure) messaging options:
[hidden email]
[hidden email]
[hidden email]
PGP Public Key:
https://pgp.mit.edu/pks/lookup?op=get&search=0xE1A22D58D20C6D22

Reply | Threaded
Open this post in threaded view
|

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

Thomas Frohwein-2
In reply to this post by Stuart Henderson
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 (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Stuart Henderson-6
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.