Hi Jim, On Wed, Feb 26, 2014 at 10:33:59PM -0800, Jim Kent wrote: > I'm glad you isolated it to the -O2.
:-) > I don't think there's a super easy way to cut pslCheck out of the whole > 1,200,000 UCSC genomics source tree. For the moment I simply disabled this check. I guess it is also this way sufficient to detect potential problems (and it was not the pslCheck that failed in the first place). > I would, on the other hand, be very > happy for you to take on the job of packaging up that whole source tree for > Debian. I could refer you to a less busy member of my staff, Hiram > Clawson, who has a _lot_ of experience helping people get that to build. This is a very cool offer. I actually have thought about packaging the whole UCSC genomics source tree as well since it obviously contains several tools that perfectly fit in our scope. I wonder whether Hiram might even like to learn something about Debian packaging. In our team we have quite some tradition in mentoring people as you can see here: https://wiki.debian.org/DebianMed/MoM Perhaps it comes handy if somebody in your team is capable to create Debian packages which in the end is not more than wrapping up the build process into some sceme. BTW, when I inspected the jksrc source tree (and also in the specific case of the blat source) I realised that it might make real sense to enable dynamic linking of the tools against the static libraries you are creating. The Debian way to do this would be to create two packages: lib<name> containing the dynamic libraries lib<name>-dev containing the static libraries and header files To approach this easily it is quite convenient to use either GNU automake or cmake (at your preference) since these build systems easily support the creation of dynamic and static libraries in parallel. This would also simplify the hancling of MACHTYPE in your makefiles since these Build systems are capable to handle this automatically. In short: before we might start packaging the whole source tree it would be quite sensible to switch to an advanced build system which would be also in your profit at the end. > The licensing of it is quite complex alas. There are three main parts: > > - a small part which is owned by me in a directory called jkOwnLib, and in > the blat directories This would probably make a separate library package. However, you might consider a name which is more descriptive than jkOwnLib. > - a medium sized part that contains stuff we regard as generally useful > which is essentially public domain, but that we are happy distributed under > a BSD or MIT license Cool. That would be very interesting. > - a large part that is genomics in general, and UCSC Genome Browser in > particular specific that is owned by UCSC and has a license much like blat > - free for personal, academic, and non-profit use, and requiring a license > for commercial use. In this case the licence needs to come from UCSC > (contact Will Hale) rather than Kent Informatics (contact Heidi Brumbaugh). In case we have a good plan about the technical details we should probable contact these persons regarding the licensing. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
