>You have access to upstream source VCS? If not, an own Git repository >under the hood of GitHub would be nice. It has the advantage that >users may report bugs directly to FB.
Ok, let me look into it. I liked pulling from theirs in the build instructions and it looked official. >But let me rewind first. You can create a basic Debian chroot environment >with: >debootstrap --arch selected_arch sid /place/the/chroot/dir/here/ >http://http.debian.net/debian/ >Where selected_arch can be i386 or amd64 (or any architecture FB may use). >Then download, build and install my patched libevent 1.4.x to that >chroot environment. >The following build dependencies are identified for HHVM 2.0: >cmake >binutils-dev >libevent-dev >libreadline-dev >libedit-dev >libncurses5-dev >libbz2-dev >libxml2-dev >libmemcached-dev >libicu-dev >libgd-dev >libcap-dev >libmcrypt-dev >libcurl4-gnutls-dev >libtbb-dev >libc-client2007e-dev >libpcre3-dev >libinotifytools0-dev >libmysqld-dev >libboost1.54-dev >libboost-system1.54-dev >libboost-program-options1.54-dev >libboost-filesystem1.54-dev >libboost-regex1.54-dev >libgoogle-glog-dev >libelf-dev >libdwarf-dev >libonig-dev >Yes, that page is highly outdated. I think Standards-Version 3.9.2 is >obsoloted now (the current one is 3.9.5) and that page uses 3.8.1! >Debhelper level should be 9 and not 7, debian/rules may use the short >debhelper format. Yikes. Can yo update it please? >Last but not least that wiki forces HHVM to be amd64 >only. Any reason to do that? Any known problem to run HHVM on >kfreebsd-*, mips{,el}, sparc or any other archs that Debian supports? Absolutely. HHVM is a Just-In-Time compiler which emits assembly code into memory then executes it. We currently only emit 64bit x86. We are looking at other backends, but they require a lot of effort to implement and optimize. >To answer your question, the proper package build is using pbuilder or >sbuild (I prefer the former). But until I can't build HHVM by hand, I >don't want to put time into packaging. I've just realized that HHVM >embeds other codes under hphp/third_party/ , even folly which is an >other FB FOSS software and should be packaged separately. Folly is pulled in with a git submodule, but yes, the others are copied in. > Especially >that now (for me) building HHVM fails with: >Linking CXX executable gen-class-map >CMakeFiles/gen-class-map.dir/gen-class-map.cpp.o: In function >`folly::TypeError::TypeError(std::string const&, >folly::dynamic::Type)': >gen-class-map.cpp:(.text._ZN5folly9TypeErrorC2ERKSsNS_7dynamic4TypeE[_ZN5f >olly9TypeErrorC5ERKSsNS_7dynamic4TypeE]+0x2a): >undefined reference to >`folly::dynamic::TypeInfo<std::vector<folly::dynamic, >std::allocator<folly::dynamic> > >::name' >[...and so on...]. > >But the embedded folly was compiled normally (the problem can be that >it's a static library but gen-class-map linking may look for a dynamic >one): >Linking CXX static library ../../../bin/libfolly.a >[ 3%] Built target folly > >This further emphasize that folly[1] should be packaged separately. Hmm, try rm CMakeCache.txt And follow the instructions https://github.com/facebook/hhvm/wiki/Building-and-installing-HHVM-on-Debia n-7 . That worked for me last week. >System libsqlite3-dev should be used as well, instead of embedding it >and so on. An other library which is in my hand in Debian and some >extra compilation options may be discussed if needed. Sure, we¹d be happy to take patches to do that. I think they are embedded since those libraries aren¹t readily available easily and this is the best way to alleviate developer pain. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ce9fa909.51a93...@fb.com
