Bug#570709: packaging hhvm
On Tue, Nov 5, 2013 at 11:26 PM, Paul Tarjan <pt@fb.com> wrote:
>>Can Facebook do the fork then?
>
> Sure. How do you want us to fork it? Our current method is pinning to a
> tag in their branch and a .patch file.
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.
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
> We haven¹t put the effort into any other event library. Our web server is
> already a pretty small proportion of our request time so inventing time in
> it is less impactful than HHVM optimizations.
Still, I've read somewhere that FB has its own C event library.
> Yes, at some point we will switch our server to us it and open source it.
> No ETA on that project though and I¹d rather not gate the packaging of
> this on it.
Sure, no problem with this.
> My main problem is getting the compile to be automatic and clean up
> correctly. Starting from your working copy would help me understand the
> correct way to do it. I was originally following [4] but then I was told
> it was outdated so I¹m fighting through another version.
>
> [4] https://github.com/facebook/hhvm/wiki/Build-Packages-for-Debian
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. 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?
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. 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[_ZN5folly9TypeErrorC5ERKSsNS_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.
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.
Regards,
Laszlo/GCS
[1] https://github.com/facebook/folly
Reply to: