[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seqan moved from svn to Git



Hi Kevin,

On Wed, Sep 23, 2015 at 09:05:37AM +1000, Kevin Murray wrote:
> >   Unknown CMake command "cmake_parse_arguments".
> > Call Stack (most recent call first):
> >   tests/cuda/CMakeLists.txt:26 (seqan_setup_cuda_vars)
> > 
> >  
> > -- Configuring incomplete, errors occurred!
> > See also "/tmp/buildd/seqan-2.0.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeOutput.log".
> > dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None returned exit code 1
> > debian/rules:19: recipe for target 'build' failed
> > ...
> > 
> > 
> > As far as I understand
> > 
> >    manual/source/BuildManual/UsingFindSeqAnCMakeModule.rst 
> > 
> > and
> > 
> >    util/cmake/SeqAnBuildSystem.cmake
> > 
> > SEQAN_HAS_CUDA should be autodetected.
> > 
> > Any idea?
> > 
> 
> I'm re-building this in pbuilder, and will keep you posted.

Thanks.
 
> On a separate note, what do you think of the idea of having a different binary
> package for each of the seqan applications, as opposed to one big seqan-apps.

That's fine for me ... if somebody else would implement it. :-)  I'm a
bit afraid about the burden of maintenance since the different binaries
might change from release to release and might require extra builds to
reflect this which is quite time consuming.  But in principle I'm a fan
of modularisation if it is worth the effort.  Currently we have a popcon
for seqan-apps of 5 active users.  So it is not a high number of systems
that is "bloatet" by extra unneeded binaries.  If you see an advantage
for your personal work - just do it.

Kind regards

     Andreas.

-- 
http://fam-tille.de


Reply to: