I question whether the following four steps should be considered a "tremendous headache", simply because of the fact that one needs to download a different file than the one already downloaded...
1. Download source tarball 2. Unpack source tarball 3. Navigate to server/src/main/c++ 4. Run "make" ... but I can easily add it back in if that's the consensus. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 13, 2013 at 11:34 AM, John Vines <vi...@apache.org> wrote: > That sounds like a tremendous headache for the users where the pre-built > native libraries aren't sufficient. > > > On Mon, May 13, 2013 at 11:13 AM, Christopher <ctubb...@apache.org> wrote: > >> Yeah, you could essentially unpack the source over the binary... for >> now, anyway... but some things would be slightly different. Like the >> addition of the proxy/thrift directory for the generated thrift >> bindings pulled out of proxy/target/. But... I really don't think it >> should be a goal to make the source directory structure and the binary >> directory structure overlap like this. The binary tarball should >> really just a "ready to use" thing, and the source should be a "ready >> to develop or re-package" thing. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi >> <billie.rina...@gmail.com> wrote: >> > On Sun, May 12, 2013 at 8:45 PM, Christopher <ctubb...@apache.org> >> wrote: >> > >> >> I went through all the rpms and debs and tarballs to check to see if >> >> they were including the right things (ACCUMULO-1404). >> >> >> >> Personally, I don't think they should be in a binary-release... source >> >> code that needs to be compiled sounds like something you'd get out of >> >> the source tarball, so I assumed its inclusion was an oversight that I >> >> was correcting. (I did make sure the *.so files were included.) If >> >> there's a reason to keep source code in a binary package, then, I can >> >> add it back in, but really, if you can't use it out of the box, I'm >> >> not sure it should be in the binary tarball. >> >> >> > >> > This would be a change from what we were doing with "dist" releases, but >> I >> > am not necessarily against it. I find it nice to have the source there, >> as >> > I often look things up in it. To reproduce the previous structure, >> would I >> > be able to just unpack the source release over the binary release? >> > >> > Billie >> > >> > >> >> This is related to another issue I was looking at also, so i'll mention >> it >> >> here: >> >> What do we include for proxy thrift bindings? I see that currently >> >> we're dropping in the gen-rb, gen-java, and gen-py folders from the >> >> proxy thrift compilation. However, I'm not so sure we should be doing >> >> this... because: >> >> >> >> 1) we don't need to include java bindings for the proxy; compiled >> >> versions are already in the proxy jar, >> >> 2) not all packagers will even have installed thrift with the ability >> >> to produce ruby and python bindings, >> >> 3) these may or may not be helpful to any particular end user (though >> >> it's probably safe to assume ruby and python will be the most common), >> >> 4) we're not including the proxy.thrift file, which is perhaps the >> >> most important file for the proxy, and including it should be >> >> sufficient. >> >> >> >> >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> >> >> >> On Sun, May 12, 2013 at 11:22 PM, David Medinets >> >> <david.medin...@gmail.com> wrote: >> >> > I ran this command: >> >> > >> >> > git clone --branch 1.5 https://github.com/apache/accumulo.git >> >> > >> >> > then compiled to get a binary-release.tar.gz file. That gz file does >> not >> >> > seem to contain the C++ files to build the native libraries. Should >> they >> >> be >> >> > there? I don't recall hearing about removing them. >> >> >>
