cwbaker / forge Goto Github PK

I have a project set up, nothing too crazy I don't think, and when I touch render/AsciiDriver.h, the file render.cpp in which it is included should be recompiled, I think.

My main forge file is as below:

buildfile 'coin/coin.forge';

for _, toolset in toolsets('cc.*') do
    toolset:all
    {
        toolset:StaticLibrary '${lib}/machines' 
        {
            toolset:Cxx '${obj}/%1' 
            {
                'render.cpp';
            };
        };

        toolset:Executable '${bin}/machines' 
        {
            '${lib}/coin';
            '${lib}/machines';

            toolset:Cxx '${obj}/%1' 
            {
                'main.cpp';
            };
        };

        toolset:Executable '${bin}/test'
        {
            include_directories =
            {
                'thirdparty/googletest/include';
            };

            '${lib}/googletest';
            '${lib}/coin';
            '${lib}/machines';

            toolset:Cxx '${obj}/%1'
            {
                'test.cpp';
            };
        }
    };
end

The file render.cpp includes render/AsciiDriver.h and when I touch the latter file I would have expected render.cpp to be compiled, however it is not.

After running the bootstrap-windows.bat, the forge.exe is never produce.

I updated to the latest version and I get this error when building:

The type 'string' at position 1 is not 'N5sweet10build_tool9BuildToolE' as expected

I've tried doing a clean build, deleting the build directory, etc. Ended up having to roll back to 4214d75 in order to get it working again.

When I run the command...

./bootstrap/bin/forge variant=shipping install

I get the following output...

~/insertcoin/process/thirdparty/forge> ./bootstrap/bin/forge variant=shipping install
...cess/thirdparty/forge/src/forge/lua/forge/xcode/init.lua:2: module 'forge.cc.clang' not found:
	no field package.preload['forge.cc.clang']
	no file '/Users/willmbaker/insertcoin/process/thirdparty/forge/src/forge/lua/forge/cc/clang.lua'
	no file '/Users/willmbaker/insertcoin/process/thirdparty/forge/src/forge/lua/forge/cc/clang/init.lua'
	no file '/usr/local/lib/lua/5.3/forge/cc/clang.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './forge/cc/clang.so'
	no file '/usr/local/lib/lua/5.3/forge.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './forge.so'

I believe the error is because forge.cc.clang is missing, but I'm not sure where it looks for those modules. Am I running it from the wrong location?

The automatically generated Lua bindings to LuaUi::sprite() and LuaUi::font() should push values into Lua through lua_push_object() which will assign the pushed userdata a metatable to give it type information. For some reason these functions end up going through the code path that pushes light userdata without the type information provided by the metatable.

The automatic Lua binding for LuaUi::style() does the right thing but I can't see what the difference in declarations and/or definitions is.

As a workaround those Lua bindings are provided manually for now but it'd be good to work out the exact reason for this.

Relevant code exhibiting the problem (since removed from LuaUi.cpp and LuaTraits.hpp).

// ...

SWEET_LUA_TYPE_CONVERSION( gfx::Font, LuaAsPointer, "gfx.Font" );
SWEET_LUA_TYPE_CONVERSION( gfx::Sprite, LuaAsPointer, "gfx.Sprite" );
SWEET_LUA_TYPE_CONVERSION( gfx::Style, LuaAsPointer, "gfx.Style" );

// ...

LuaUi::create()
{
    // ....
    lua_->members( this )
        // ...
        ( "sprite", &LuaUi::sprite, this )
        ( "font", &LuaUi::font, this )
        ( "style", &LuaUi::style, this )
        // ...
}

const gfx::Sprite* LuaUi::sprite( const std::string& identifier ) const
{
    return ui_->sprite( identifier.c_str() );
}

const gfx::Font* LuaUi::font( const std::string& identifier ) const
{
    return ui_->font( identifier.c_str() );
}

const gfx::Style* LuaUi::style( const std::string& identifier ) const
{
    return ui_->style( identifier.c_str() );
}

/tmp/ccnBWUUP.s: Assembler messages:
/tmp/ccnBWUUP.s:1: Error: junk at end of line, first unrecognized character is `='

This only happens with GCC but has always happened on and off when building with Forge. It happens seemingly against random files compiled with GCC -- both C and C++ sources. It always complains that the first unrecognized character is =.

This happens when the write end of the pipe used to write dependencies by the injected build hooks library is already matching the requested file descriptor 3. In this case the dup2() call is a no-op, the close() call closes the write end of the pipe, and writes to the user requested file descriptor write to whichever file ends up opened to that file descriptor which is often the assembly file being written.

I was following the installation instructions and when running the following command:
bash ./bootstrap-macos.bash I got compilation errors:

~/insertcoin/process/thirdparty/forge/src/luaxx ~/insertcoin/process/thirdparty/forge
luaxx.cpp...
luaxx.cpp:503:9: error: use of undeclared identifier 'free'
        free( ptr );
        ^
luaxx.cpp:508:16: error: use of undeclared identifier 'realloc'
        return realloc( ptr, nsize );
               ^
2 errors generated.
ar: *.o: No such file or directory

This is macOS Sierra, where clang --version outputs:

Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin16.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I am using a Centos 7 environment, together with devtoolset-7 (in order to get more recent compilers).

With devtoolset enabled in a shell:

$ which gcc
/opt/rh/devtoolset-7/root/usr/bin/gcc

However when trying to build forge I get the following error for each compilation:

gcc: error trying to exec 'cc1plus': execvp: No such file or directory

cc1plus is available:

$ find /opt/rh/devtoolset-7/ -name cc1plus
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/cc1plus

Also I can compile C++ programs manually or using other build systems, so I think it must be something specific to Forge that is causing this.

Dropping back to the regular gcc supplied with Centos 7 allows it to build successfully.

What does "AFX" stand for?

It's silly, I know, but I'm a little stuck with it right this second.

When I run a build.lua that contains nothing but require "build"; then I get the output C stack overflow.

LuaSystem.cpp...
In file included from /root/forge/src/meow_hash/meow_intrinsics.h:34:0,
from LuaSystem.cpp:17:
/usr/lib/gcc/aarch64-linux-gnu/7.3.0/include/arm_neon.h: In function ‘meow_aes_128 Meow128_AESDEC(meow_aes_128, uint8x16_t)’:
/usr/lib/gcc/aarch64-linux-gnu/7.3.0/include/arm_neon.h:12433:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesdq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
vaesdq_u8 (uint8x16_t data, uint8x16_t key)
^~~~~~~~~
In file included from LuaSystem.cpp:17:0:
/root/forge/src/meow_hash/meow_intrinsics.h:168:22: note: called from here
R.A = vaesimcq_u8(vaesdq_u8(Prior.A, Prior.B));
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /root/forge/src/meow_hash/meow_intrinsics.h:34:0,
from LuaSystem.cpp:17:
/usr/lib/gcc/aarch64-linux-gnu/7.3.0/include/arm_neon.h:12447:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesimcq_u8(uint8x16_t)’: target specific option mismatch
vaesimcq_u8 (uint8x16_t data)
^~~~~~~~~~~
In file included from LuaSystem.cpp:17:0:
/root/forge/src/meow_hash/meow_intrinsics.h:168:22: note: called from here
R.A = vaesimcq_u8(vaesdq_u8(Prior.A, Prior.B));
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LuaTarget.cpp...