A great proposal!<br><br>Perhaps the following ideas are more radical than you had in mind, but here's my thoughts:<br><br>- paraview superbuild cmake scripts are not in a separate repo, they are part of paraview<br>- paraview superbuild becomes the standard way to build paraview all the time. By default USE_SYSTEM_{QT,PYTHON,MPI} are enabled<br>
- vtk is an external project, vtk is no longer a git submodule in paraview (we still build against the pv branches of course)<br>- make as much as possible an external project, externalize IceT, protobuf, etc.<br> If patches are required to any of these 3rd party libraries, then we maintain git forks of the projects,<br>
with our patches as commits, then its easy for the maintainers of these projects to take our patches upstream.<br><br><br>Pat<br><br><br><div class="gmail_quote">On Tue, Mar 27, 2012 at 1:28 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com">utkarsh.ayachit@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Different people imply different things when they say they want to<br>
generate a package for ParaView. Some, like the official binary<br>
builders here at Kitware, imply that the package is a complete tarball<br>
with minimal external run-time dependencies. Others, like those that<br>
build packages for linux distros, want the package to 'depend' on<br>
external libraries they specify. Still others, are building on HPC<br>
systems that require cross compiling or specific environment setup<br>
with some dependencies available and others not.<br>
<br>
In the past ParaView build/install cmake rules themselves tried to<br>
address all these cases and as expected failed to address all these<br>
concerns at all the times.<br>
<br>
Enter CMake External Projects or Superbuilds. These are meant to be<br>
used for building projects that depend on other projects. We started<br>
playing with using superbuilds for ParaView packaging starting with<br>
3.12. With our experience with 3.14 builds, it seems like superbuild<br>
may just be the panacea we were looking for. If we follow the<br>
following simple rules, it seems like we may be able to address all<br>
the necessary use-cases.<br>
<br>
1. ParaView (and VTK)'s "make install" will never install any external<br>
dependencies. The mantra will be "you install what you build". Thus<br>
people who expected "make install" to install Qt, FFMPEG, Python --<br>
sorry! "make install" is not for you. You should use<br>
ParaView-Superbuild to generate a "complete package" and then install<br>
it where ever you like.<br>
<br>
2. A separate git repository will host what we call the<br>
ParaView-Superbuild. These will be cmake files that know how to build<br>
ParaView and all its dependencies for generating packages.<br>
<br>
3. ParaView-Superbuild also follows the same principle as ParaView<br>
i.e. "package what you build". However unlike ParaView,<br>
ParaView-Superbuild will know how to build all dependencies for<br>
ParaView including zlib, libpng, hdf5, Python, numpy and even Qt.<br>
<br>
4. ParaView-Superbuild will have top-level options to build<br>
with/without Qt or GUI Support or build with OS Mesa (when Qt GUI is<br>
disabled). These top level options will make it easier to build<br>
packages with Qt application or just command line server-side tools.<br>
<br>
5. While ParaView-Superbuild will build all dependencies by default,<br>
there were be options for a few subprojects to use system versions.<br>
Thus, we can choose to use system Python, Qt, MPI, or HDF5.<br>
<br>
6. One can then use cpack to generate a package with all dependencies<br>
that were built in the ParaVIew-Superbuild. For system dependencies,<br>
cpack will ensure that the rpath is setup to include the path where<br>
those are present e.g. if use chose to use system Qt, then the package<br>
will be missing any Qt libraries but will have rpath (where<br>
applicable) setup to point to where the Qt was located during builds<br>
so that the user doesn't have to setup the paths when running. Of<br>
course in this case the binary may not work if simply moved to another<br>
machine, but then you want to let superbuild build all the<br>
dependencies on its own.<br>
<br>
7. Finally superbuild will also support cross-compiling as well as<br>
using external VTK. (I haven't thought about either much at this point<br>
to say exactly how that would happen, but it needs to).<br>
<br>
How does every feel about this approach? Any comments? Thoughts?<br>
<br>
To get a feel for what this ParaView Superbuild may look like, look at<br>
the "v3.14.0" tag on this temporary git repo:<br>
<a href="https://gitorious.org/paraview-collaboration/paraview-binaries-superbuild" target="_blank">https://gitorious.org/paraview-collaboration/paraview-binaries-superbuild</a><br>
<br>
This is an experimental repo that only works on linux for now, but it<br>
should clarify a few things discussed here.<br>
<br>
Utkarsh<br>
_______________________________________________<br>
Paraview-developers mailing list<br>
<a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
</blockquote></div><br>