Mathieu,

In my opinion the proposed package split and supported platforms makes sense, but I can't speak for the whole VXL community.  From my point of view, if there is another package that actually depends on vxl-contrib and wants to build on an unsupported platform, then someone should post a message to this mailing list and state which libraries from contrib are needed.  That process validates that the contrib library is being used by more than just by its original author and provides motivation to move the library to core.

The need to run cmake twice sounds like a work-around to me.  I think there is actually some issue that still needs to be resolved.

Joe, 

All of these issues and the proposed patches relate to the BRL section of contrib, mostly the boxm library.  Do you think you or one of your students can validate that these patches should be applied?  Can you validate that it is safe to remove the extra template instantiation?  Can you find a fix for the compile error when CMake is only run once?

Brad King has just set up a new "release" branch for VXL that currently points at the 1.17.0 release.  We have a Git workflow in mind to use the release branch to create a VXL 1.17.1 release that contains fixes for all of these issues.  I will describe the workflow in a separate e-mail, and I can help with the Git side of things, but I would like someone at Brown to validate these patches and provide fixes for the other issues.

Thanks,
Matt 


On Wed, May 29, 2013 at 8:00 AM, Mathieu Malaterre <malat@debian.org> wrote:
Matt,

  That's seems pretty clear. I'll split the current binary vxl package
into two (-core & -contrib). The -contrib one will only be available
on:

amd64 i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386

Or (just for clarity) it won't be available on those platforms:

alpha armel armhf ia64 mips mipsel powerpc powerpcspe s390 s390x sparc
hppa m68k ppc64 sh4 sparc64 x32

  As a side note, I could go passed the previous compilation error
using two cmake configure steps (looks like a cached cmake variable is
being used before being set). So consider this issue solved.

  To get things running I also removed completely any tests within
contrib (some tests seems to hang, and thus would prevent from having
vxl build on a particular platforms):

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/vxl/trunk/debian/patches/remove_contrib_testing.patch?view=markup

I have solved the arm* compilation error by removing:

contrib/brl/bseg/boxm/pro/Templates/boxm_scene+boct_tree+short.vnl_vector_fixed+float.3---.cxx

which seems to be a (partial?) duplicate of
boxm_block+boct_tree+short.vnl_vector_fixed+float, see:

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/vxl/trunk/debian/rules?view=markup

  To get opencl module to build on linux, I had to use a couple more patches:

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/vxl/trunk/debian/patches/opencl_unix.patch?view=markup

and

http://anonscm.debian.org/viewvc/debian-med/trunk/packages/vxl/trunk/debian/patches/ocl_comp.patch?view=markup

Enjoy,
-M

On Tue, May 28, 2013 at 3:46 PM, Matt Leotta <matt.leotta@kitware.com> wrote:
> Mathieu,
>
> What I was thinking is the vxl-core should support all architectures that
> debian requires and vxl-contrib would support an explicit list of
> architectures, probably just the more common ones used in desktop computers
> (i386, amd64, etc.).  VXL core is a more stable set of libraries with a
> stricter set of design requirements, and it would be easier to keep VXL core
> working on a wider array of architectures.  VXL contrib, at least the parts
> of it that tend to cause these issues, are rapidly evolving research
> libraries that are really targeted toward a smaller number of architectures
> and users.  It's possible that you don't need to package VXL contrib at all.
> If other packages are depending on VXL for a library that is in contrib,
> that is a good sign that the contrib library should be moved to core, and
> that request should be made to the VXL maintainers to do so.
>
> The answer to "which platforms does VXL run on?" is whatever platforms are
> submitting nightly builds to the dashboard
> (http://open.cdash.org/index.php?project=vxl).  This used to be a much
> larger list, and we need to encourage more users to submit dashboard builds
> to keep VXL working on more platforms.  In general, if you want VXL to
> support your platform you need to submit a nightly build to the dashboard
> using that platform so we can see what the issues are.
>
> I don't expect it to be too difficult to fix this particular issue.  I
> assume someone from Brown University can resolve this issue without too much
> trouble.  The problem is that VXL has historically had an overly simple
> release process.  We just pick a commit every 6 month or so (usually longer)
> when the dashboard is clean and call that a stable release.  We do not go
> back apply fixes to the release.  So your current issue might get fixed in
> the next release, but it's likely that other issues may also arise in newly
> developed code.  We are not trying to hide anything, our releases are bound
> to have bugs; historically, we just haven't fixed bugs on stable releases.
> VXL has been developed by and for its maintainers and stable release have
> had lower priority.
>
> While the above summarizes the current state of the VXL release process, I
> don't believe it has to be this way.  A primary motivation for VXL's recent
> move to Git was to fix these issues in the process.  I am giving the VXL
> maintainers some time to adjust to Git, but I think fairly soon we can
> establish a "release" branch for the purpose of maintaining bug fixes on
> stable releases.  We could start this branch at 1.17, apply fixes for this
> issues, and release 1.17.1.
>
> Lianqing, if Brad and I establish a release branch for vxl 1.17, and a Brown
> University developer provides a fix for the issue in question, would you be
> willing to try using Git to make a 1.17.1 release?  I can provide
> instructions/help as needed.
>
> Thanks,
> Matt
>
>
>
> On Mon, May 27, 2013 at 7:56 AM, Mathieu Malaterre <malat@debian.org> wrote:
>>
>> Matt,
>>
>>   Point taken. However debian package system is not that flexible. You
>> would need to have it coded somewhere that 'vxl-contrib does not build
>> on mips* arm*'. Which comes back to a previous question: "which
>> platforms does VXL runs on ?".
>>   It also would not solve the issue that a shared library is being
>> shipped with a missing symbol, this makes it AFAIK pretty much useless
>> when linking to an executable. Finally as part of the debian team, I
>> have agreed to the Debian Socal contract [1], which states "We will
>> not hide problems". I would feel rather uncomfortable if I were to
>> upload VXL again simply changing the option from ON back to OFF.
>>
>>   Anyway as described in the debian bug report, the issue can be seem
>> on all platforms (i486, amd64...). The instructions are pretty clear
>> so anyone can simply copy/paste to reproduce the issue. Therefore
>> there is good chance, this may get fixed at some point. The next
>> release of debian is in about ~3years which leaves plenty of time  for
>> fixes.
>>
>> Thanks,
>>
>> [1] http://www.debian.org/social_contract
>>
>> On Fri, May 24, 2013 at 6:07 PM, Matt Leotta <matt.leotta@kitware.com>
>> wrote:
>> > Mathieu,
>> >
>> > This doesn't help your immediate issue, but in the future it might make
>> > sense to move to toward multiple debian packages for VXL.  A vxl-core
>> > package for the core libraries and a vxl-contrib package for the contrib
>> > libraries that depends on vxl-core (or possibly even packages for each
>> > contrib directory).  In general, VXL's core libraries are much more
>> > stable
>> > and better tested across various platforms than the contrib libraries.
>> > You
>> > wouldn't have to worry about breaking the core package every time
>> > something
>> > breaks in contrib.
>> >
>> > At Kitware, we've been talking about cleaning up and modernizing the
>> > CMake
>> > build scripts in VXL.  Making it easier to package things separately
>> > could
>> > be on that to do list.  If you think there is benefit to that we should
>> > discuss it further.
>> >
>> > In terms of your current issue, I don't have a patch for you.  If I did
>> > have
>> > a patch, this would be a good use case for having a 'release' branch in
>> > git
>> > that is updated with critical fixes like this for the current stable
>> > release.  I think it's a bit too soon to change git workflows in VXL,
>> > because VXL maintainers are still getting used to git, but some day we
>> > should be able to support that.  That way these patches don't just live
>> > in
>> > the debian package source.
>> >
>> > --Matt
>> >
>> >
>> >
>> >
>> > On Fri, May 24, 2013 at 11:33 AM, YuLianqing <yulq@live.cn> wrote:
>> >>
>> >> Hi, Mathieu,
>> >>
>> >> I was responsible for the release of VXL 1.17.0 last year. I compiled
>> >> the
>> >> source code on two Linux servers (one is CentOS 5 and the other is
>> >> RHEL6)
>> >> and a number of PCs running Windows XP to 7. Other maintainers also
>> >> tested
>> >> the release on their own machines including Sean's Macs. We did not
>> >> find
>> >> build errors and then decided to make the release.
>> >> As I have no debian system at hands at this moment, I thought it may be
>> >> helpful to contact the author of BRL library. The last resort is
>> >> disable the
>> >> build of BRL by setting BUILD_BRL to off in CMake script.
>> >>
>> >> Best regards,
>> >> Lianqing
>> >>
>> >> > From: malat@debian.org
>> >> > Date: Fri, 24 May 2013 13:13:23 +0200
>> >> > To: vxl-maintainers@lists.sourceforge.net
>> >> > Subject: [Vxl-maintainers] VXL 1.17.0 status in debian
>> >>
>> >> >
>> >> > Dear VXL-maintainers,
>> >> >
>> >> > Here is the current status of VXL 1.17.0 in debian:
>> >> >
>> >> > https://buildd.debian.org/status/package.php?p=vxl
>> >> >
>> >> > As you may noticed, VXL fails to build on mips* platforms. The issue
>> >> > on those platforms is that it is not possible to have a shared
>> >> > library
>> >> > with an undefined symbol:
>> >> >
>> >> > ../../../../../../lib/libbwm.so.1.17.0: undefined reference to
>> >> > `bwm_observer_cam::backproj_point(vbl_smart_ptr<vsol_point_2d>,
>> >> > vbl_smart_ptr<vsol_point_3d>&, vgl_plane_3d<double>)'
>> >> > collect2: ld returned 1 exit status
>> >> >
>> >> > As explained in great details, libbww.so leaves an undefined symbol:
>> >> >
>> >> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708131
>> >> >
>> >> > What this means is that if I cannot get passed this compilation
>> >> > error,
>> >> > I'll be requested to remove VXL from debian, as this is considered a
>> >> > regression (VXL 1.14.0 builds fine mips*). So I'd really appreciate
>> >> > if
>> >> > someone could provide a patch to get passed this compilation error.
>> >> >
>> >> > Technically VXL fails to build on arm* [1] so I would need to fix the
>> >> > compilation error on those platforms too, but the error is much
>> >> > easier
>> >> > to solve, so I have not provided a patch for it for now.
>> >> >
>> >> > For references, here are the current patches needed to get VXL 1.17.0
>> >> > to compile on debian (x86* and ppc):
>> >> >
>> >> > http://patch-tracker.debian.org/package/vxl/1.17.0-3
>> >> >
>> >> > Regards,
>> >> >
>> >> > [1]
>> >> >
>> >> > https://buildd.debian.org/status/fetch.php?pkg=vxl&arch=armel&ver=1.17.0-3&stamp=1369214985
>> >> > [...]
>> >> >
>> >> >
>> >> > CMakeFiles/boxm_pro.dir/Templates/boxm_scene+boct_tree+short.vnl_vector_fixed+float.3---.o:(.rodata+0x0):
>> >> > multiple definition of `typeinfo name for boxm_scene<boct_tree<short,
>> >> > vnl_vector_fixed<float, 3u> > >'
>> >> >
>> >> >
>> >> > CMakeFiles/boxm_pro.dir/Templates/boxm_block+boct_tree+short.vnl_vector_fixed+float.3---.o:(.rodata+0x0):
>> >> > first defined here
>> >> >
>> >> >
>> >> > CMakeFiles/boxm_pro.dir/Templates/boxm_scene+boct_tree+short.vnl_vector_fixed+float.3---.o:(.data.rel.ro+0x0):
>> >> > multiple definition of `typeinfo for boxm_scene<boct_tree<short,
>> >> > vnl_vector_fixed<float, 3u> > >'
>> >> >
>> >> >
>> >> > CMakeFiles/boxm_pro.dir/Templates/boxm_block+boct_tree+short.vnl_vector_fixed+float.3---.o:(.data.rel.ro+0x0):
>> >> > first defined here
>> >> > collect2: ld returned 1 exit status
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Try New Relic Now & We'll Send You this Cool Shirt
>> >> > New Relic is the only SaaS-based application performance monitoring
>> >> > service
>> >> > that delivers powerful full stack analytics. Optimize and monitor
>> >> > your
>> >> > browser, app, & servers with just a few lines of code. Try New Relic
>> >> > and get this awesome Nerd Life shirt!
>> >> > http://p.sf.net/sfu/newrelic_d2d_may
>> >> > _______________________________________________
>> >> > Vxl-maintainers mailing list
>> >> > Vxl-maintainers@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Try New Relic Now & We'll Send You this Cool Shirt
>> >> New Relic is the only SaaS-based application performance monitoring
>> >> service
>> >> that delivers powerful full stack analytics. Optimize and monitor your
>> >> browser, app, & servers with just a few lines of code. Try New Relic
>> >> and get this awesome Nerd Life shirt!
>> >> http://p.sf.net/sfu/newrelic_d2d_may
>> >> _______________________________________________
>> >> Vxl-maintainers mailing list
>> >> Vxl-maintainers@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>> >>
>> >
>
>