On 2013/10/06 10:09 AM, Ian Thomas wrote: > Fellow developers, > > I am working on a PR to replace the use of matplotlib.delaunay with the > Qhull library. Installation will be similar to the existing packages > LibAgg and CXX in that if the system already has a sufficiently recent > version of Qhull installed then matplotlib will use that, otherwise it > will build the required library from the source code shipped with > matplotlib. > > I have a thin C wrapper called qhull_wrap.c (following the coding > guidelines) which I'll put in the top-level src directory along with > most of the existing C/C++ extensions. But my question is where to put > the qhull source code? > > Current practice has separate top-level directories called agg24 and CXX > for the LibAgg and CXX packages respectively, so my initial thought was > to follow this and create a new top-level directory called qhull to > place the library code in. But I don't like this approach of creating a > new top-level directory as (1) I think the top-level should remain as > simple and uncluttered as possible, (2) it tends to overemphasize the > importance of these third-party libraries as they are some of the first > directories users see when unzipping the mpl tarball, and (3) it is not > immediately obvious that the code in these directories is from > third-party libraries rather than something we ourselves have written. > > Hence my preference is to create a new top-level directory called > something like 'third-party' (or should that be 'third_party'?), and > place all the third-party libraries in that; i.e. move the agg24 and CXX > directories into third-party, and place the new qhull source code in > third-party/qhull. > > What do others think of this idea?
Adding this top-level directory is OK with me, but since I hope we will not need to carry along very many of such library source trees, it doesn't seem so important to segregate them in this way. If you do, alternative names might be "dependencies" or "external". The contents don't necessarily match what can be found elsewhere; Mike has needed to make local patches on occasion. Eric > > Ian Thomas ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
