Bug#570709: packaging hhvm
On Wed, Nov 6, 2013 at 5:51 PM, Paul Tarjan <pt@fb.com> wrote:
>>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.
Please do realize we are talking about a FB fork. Reasons are:
- upstream moved forward (rewrote the API and has 2.x version)
- upstream no longer support 1.y, but FB still needs it -> 'owner' of
the code transition to FB
- 1.y is for FB only, any compile or runtime bug affects its source: HHVM
- need a central place to report bugs to FB without mixing original
upstream (2.x) bugs.
Considering the above, FB needs an own place to host 1.y source.
>>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?
Will do. As I see, the first step should be to package folly.
>>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.
Removed that chroot, but can be recreated anytime. But please,
remember that all uploads go to unstable and should be built in an
up-to-date unstable chroot. It makes the mentioned page highly
outdated as Sid has gcc/g++ 4.8, PHP5 5.5.5 (not 5.4.4) and Boost
libraries 1.54 (not 1.49) among others.
>>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.
I don't know (yet) if any patch is needed to use the external
libraries; but 'rm -rf hphp/third_party/' would be the start. For me
several libraries can be installed with apt-get like:
apt-get install liblz4-dev libsqlite3-dev libdouble-conversion-dev
... maybe others as well. Thus they are available easily.
Reply to: