Can't compile bytecode VM on Fedora (gyp error)

[relrod]

trafficstars

I'm trying to compile the bytecode VM on Fedora (19 alpha) and hitting an error:

ricky@t520 /tmp/magpie (master)$ ./run_gyp 
gyp: name 'host_arch' is not defined while evaluating condition 'host_arch != target_arch and target_arch=="ia32"' in magpie.gyp while trying to load magpie.gyp

Some system info:

Linux t520.home.elrod.me 3.9.0-0.rc8.git0.2.fc19.x86_64 #1 SMP Wed Apr 24 18:25:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora release 19 (Schrödinger’s Cat)

Let me know if I can provide any more information :)

[munificent]

Interesting. My gyp knowledge is pretty pathetic (though not as pathetic as gyp's documentation). I mostly just copy stuff from V8 until things start working. Can you try adding this:

'target_arch%': 'ia32',          # set v8's target architecture
'host_arch%': 'ia32',            # set v8's host architecture

To line 4 of common.gypi and see if that fixes it? If it does, I'll add that in (or you could throw a pull request at me :smile:).

[relrod]

Well that gets us a step closer.

I now have a magpie.target.mk and unit_tests.target.mk, but no Makefile.

If I try to force make to use magpie.target.mk, I get this:

ricky@t520 /tmp/magpie $ make -f magpie.target.mk all
make: *** No rule to make target `.target/../dep/libuv/libuv.a', needed by `.target/magpie/../src/Base/MagpieString.o'.  Stop

I'm happy to send a PR, once we get it building - and I'll update documentation along with it. :)

[Sh4rK]

This is a bit off-topic, but how about switching to some other build system, like CMake? In my experience it works pretty well, it's more stable than gyp, and it has documentation. It also allows one to select which compiler to use (eg. MSVC or mingw on Windows), which I think gyp can't do currently.

[munificent]

I don't love gyp, but I don't really love any build system. They all seem to be a pain. I think I toyed with CMake once a long time ago. This is perhaps getting hung up on trivia, but the CMakeLists files it litters throughout the source tree drove me crazy.

I went with gyp for a few reasons:

1. I work at Google on the Dart project, which is part of the Chrome organization, so I'm surrounded by people who know gyp.
2. While its documentation sucks, it's simple, fast, and seems to cover the sweet spot that I care about: Mac, Windows and Linux; Xcode, make, and VS.
3. Magpie uses libuv which itself uses gyp so I think this makes it a bit easier to integrate.

My general take on build systems is that they are a necessary evil. I think you just pick one that works, wrap it up in a few scripts and try to spend as little time as possible futzing with it. :)

[relrod]

@munificent Any idea how to get a working Makefile out of it? ;)

[munificent]

Oh, sorry @CodeBlock, forgot to reply to your comment. :)

I'm not sure what's going on there. I'll have to get on a Linux machine myself and try to poke around at it. I don't have one at home, but I may be able to use a work machine for a bit. Until then, your guess is as good as mine. :(

[relrod]

I'm happy to spin up an EC2 or DigitalOcean instance and give you access to it, if you'd like and if it would help. Let me know! :)

[ghost]

@CodeBlock I realize the other comments on this issue were two months ago, so I have no idea if this is still a problem. I am on Debian, and after making the changes to common.gyp that @munificent mentioned above, I had the two .mk files you mentioned, as well as a directory called 1, with a Makefile in it. cd 1 && make successfully compiled everything into 1/out.

[relrod]

@untothebreach I'll give this a shot soon. Thanks!