Re: blast+ packaging
That's a puzzling error; please send your c++/config.log, which should shed more light on it. Thanks!
-- Sent from my Palm Pre
On May 30, 2011 3:44, Olivier Sallou <olivier.sallou@irisa.fr> wrote:
hi,
after updating to your code, there is a compil (configure) error at
build time:
configure: error: Do not know how to build MT-safe with compiler
/usr/bin/g++
Maybe a missing dependency, do you have any idea?
Olivier
Le 5/29/11 6:12 PM, Aaron M. Ucko a écrit :
> Olivier Sallou <olivier.sallou@irisa.fr> writes:
>
>> please feel free to commit in my dir. It will indeed be easier than merging.
> Done, thanks. I also threw in some improvements to the copyright file that
> I'd meant to propose earlier:
>
> * Remove the stanza for (c++/)scripts/projects/xmlwrapp/*, whose LICENSE
> file documents material absent from the ncbi-blast+ archive.
> * Adjust other upstream-related stanzas' Files specifications to prefix
> c++/ and cover include in addition to src as appropriate.
>
>> For dir updates, be it ncbi-blast+ or ncbi-blast-plus, I would rather
>> like you update directly in my branch. We can, after that, "mv" the svn
>> dir to ncbi-blast+ once everything is ok from packaging point of view.
> That's fair, and no problem -- quite the contrary, when I was starting to
> commit to ncbi-blast+ (before the Alioth glitch and your latest reply), I
> didn't split my changes into individual commits quite as cleanly as I'd
> meant to, so re-committing them in ncbi-blast-plus gave me a good
> opportunity to correct that.
>
>> Please tell me once you have included your updates so that I recheck the
>> package on my side.
> I have. Here are the remaining issues of which I'm aware, none of which
> should necessarily hold up an initial upload:
>
> * As previously mentioned, the linkage is still somewhat of a mess.
> * Also as mentioned, there are no individual manpages.
> * The standards version is slightly outdated; somebody should review the
> upgrading checklist to see if advancing it requires any packaging changes.
> * As I recall, there was some interest in incorporating RMBLAST, the patch
> for which risked changing the standard applications' behavior. I expect
> it should be possible to stay out of trouble by building it in a separate
> copy of the source tree and linking it statically against any patched
> libraries (and their reverse dependencies).
>
>> Regarding legacy, I prefered keeping it as separate package to avoid some
>> confusion and get it only if required on backward compatibility. Though,
>> if you think we should keep it in the same package, it is ok for me.
> OK, thanks for the explanation; I've kept the split.
>
--
gpg key id: 4096R/326D8438 (pgp.mit.edu)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Reply to: