Boost logo

Geometry :

Subject: Re: [geometry] type based tag dispatching for VTK output
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-06-07 17:46:33

On 7 June 2013 21:39, Tomislav Maric <tomislav.maric_at_[hidden]> wrote:
> 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. :)

Right, thanks for clarification.

>> 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:
>> This is common practice in Boost Sandbox with misc proposals and extensions:
>> So, users can do something along these lines:
>> svn co 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
> #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..

Yes, that's sensible.

BTW, I also use/prefer CMake for my Boost-based projects.

Best regards,

Mateusz Loskot,

Geometry list run by mateusz at