Geometry Boost List: Re: [geometry] type based tag dispatching for VTK output

Subject: Re: [geometry] type based tag dispatching for VTK output
From: Tomislav Maric (tomislav.maric_at_[hidden])
Date: 2013-06-07 16:39:26

On 06/07/2013 03:53 PM, Mateusz Loskot wrote:
> On 7 June 2013 14:27, Tomislav Maric <tomislav.maric_at_[hidden]> wrote:
>> On 06/07/2013 10:51 AM, Mateusz Loskot wrote:
>>> On 7 June 2013 09:05, Tomislav Maric <tomislav.maric_at_[hidden]> wrote:
>>>> On 06/07/2013 12:20 AM, Barend Gehrels wrote:
>>>>
>>> If I may, I'd suggest to restructure the repository tree to include full path to
>>> the headers, as it is a common practice in external additions for Boost.
>>> It means, once the repo is cloned, it would be good to have:
>>>
>>> /boost/geometry/extensions/io/vtk
>>> /libs/geometry/extensions/test/io/vtk
>>>
>>> This makes it much easier to integrate your work with Boost sources tree,
>>>
>> Thank you for the tip, it's done + the repo is updated. All the test
>> apps are installed in build/bin now as well. I'm sticking with cmake for
>> now, later the include directives need to be changed to account for
>> linux FHS directories </boost/geometry/..> but there is much more to do
>> before that becomes necessary.
> I sense misunderstanding, the paths
> /boost/geometry/extensions/io/vtk
> /libs/geometry/extensions/test/io/vtk
> are not meant to denote Unix paths, but / means repository root.
> IOW, it should be read as
>
> {GIT_REPO_ROO}/boost/geometry/extensions/io/vtk
> {GIT_REPO_ROO}/libs/geometry/extensions/test/io/vtk
>
> Certainly, Boost header are never included with
> #include </boost/...>
> but just
> #include <boost/...>
I misspelled that... sorry about that, I was in a hurry. Of course, 
"#include</boost...>" makes no sense.. what I meant by FHS is the fact
that the default install prefix will make the boost sources land in
"/usr/local/include/" which is also the default include path for gcc, if
I understand things right. Then having "include <boost/...>" all over
the applications will work since the headers will be placed where the
compilers can find them. Since I am working on a detached sandbox
repository, I'm still counting on cmake. :)
>
> The point I was trying to make is to keep structure of repository of
> third-party extensions
> for Boost to be exactly the same as original structure of Boost SVN trunk:
> http://svn.boost.org/svn/boost/trunk/
>
> This is common practice in Boost Sandbox with misc proposals and extensions:
> http://svn.boost.org/svn/boost/sandbox/
>
> So, users can do something along these lines:
>
> svn co http://svn.boost.org/svn/boost/trunk/ mycopy
> cp -a {GIT_REPO_ROO}/boost mycopy/boost
> cp -a {GIT_REPO_ROO}/libs    mycopy/libs
>
> Anyway, just a loose suggestion.

That's exactly how it is set up now. The only thing is that I want to
use cmake still for app compiling since I cannot use include directives
as you would normally, e.g. for

http://svn.boost.org/svn/boost/trunk/libs/geometry/test/io/wkt/wkt.cpp

#include <boost/geometry/algorithms/area.hpp>
#include <boost/geometry/algorithms/length.hpp>
#include <boost/geometry/algorithms/num_points.hpp>
...

And for the "boost-geometry-3d/libs/geometry/extensions/test/io/vtk/vtk.cpp"

there is only '#include "write.hpp"' for now, that needs to be changed
when the sandbox code is copied as you suggested. When you clone the git
repo with "git clone git_at_[hidden]:tmaric/boost-geometry-3d", there
are "boost" and "libs" directories that correspond those in the svn
trunk now..

Best regards,
Tomislav
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry