Cycle between Graph and GraphParallel

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Cycle between Graph and GraphParallel

Boost - Dev mailing list
Currently we have a dependency cycle between `graph` and `graph_parallel`.
It's not the only one, but it's notable with the fact that both libraries
are buildable and we therefore can't ignore it as we can ignore cycles
between header-only libraries that at release time become a single
directory.

In the particular, this impedes efforts to generate CMake config files.
Under one scheme I'm currently working on, for instance, Boost.Python can't
be installed because it tries to install Graph, which tries to install
GraphParallel, which tries to install Graph.

The cycle between these two is an interesting one.
boost/graph/breadth_first_search.hpp does:

#ifdef BOOST_GRAPH_USE_MPI
#  include <boost/graph/distributed/breadth_first_search.hpp>
#endif

at its end, and boost/graph/distributed/breadth_first_search.hpp does:

#ifndef BOOST_GRAPH_USE_MPI
#error "Parallel BGL files should not be included unless
<boost/graph/use_mpi.hpp> has been included"
#endif

#include <boost/graph/breadth_first_search.hpp>

at its very start. So these headers include each other.

One would naively think that only the parallel header should include the
normal one, but one is not well versed in graph library architectures, so
one might quite possibly be missing something, or a lot.

Comments?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Cycle between Graph and GraphParallel

Boost - Dev mailing list
On 10/5/2018 8:18 PM, Peter Dimov via Boost wrote:

> Currently we have a dependency cycle between `graph` and
> `graph_parallel`. It's not the only one, but it's notable with the fact
> that both libraries are buildable and we therefore can't ignore it as we
> can ignore cycles between header-only libraries that at release time
> become a single directory.
>
> In the particular, this impedes efforts to generate CMake config files.
> Under one scheme I'm currently working on, for instance, Boost.Python
> can't be installed because it tries to install Graph, which tries to
> install GraphParallel, which tries to install Graph.
>
> The cycle between these two is an interesting one.
> boost/graph/breadth_first_search.hpp does:
>
> #ifdef BOOST_GRAPH_USE_MPI
> #  include <boost/graph/distributed/breadth_first_search.hpp>
> #endif
>
> at its end, and boost/graph/distributed/breadth_first_search.hpp does:
>
> #ifndef BOOST_GRAPH_USE_MPI
> #error "Parallel BGL files should not be included unless
> <boost/graph/use_mpi.hpp> has been included"
> #endif
>
> #include <boost/graph/breadth_first_search.hpp>
>
> at its very start. So these headers include each other.
>
> One would naively think that only the parallel header should include the
> normal one, but one is not well versed in graph library architectures,
> so one might quite possibly be missing something, or a lot.

I believe you are correct here. Boost Graph should not depend on Boost
Graph Parallel in any situation. Boost Graph Parallel is a library
end-users should be able to use as they choose and Boost Graph itself
should be usable without ever bringing in the Parallel code.

>
> Comments?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Cycle between Graph and GraphParallel

Boost - Dev mailing list
On Fri, Oct 05, 2018 at 10:43:23PM -0400, Edward Diener via Boost wrote:

> On 10/5/2018 8:18 PM, Peter Dimov via Boost wrote:
> > Currently we have a dependency cycle between `graph` and
> > `graph_parallel`. It's not the only one, but it's notable with the fact
> > that both libraries are buildable and we therefore can't ignore it as we
> > can ignore cycles between header-only libraries that at release time
> > become a single directory.
> >
> > In the particular, this impedes efforts to generate CMake config files.
> > Under one scheme I'm currently working on, for instance, Boost.Python
> > can't be installed because it tries to install Graph, which tries to
> > install GraphParallel, which tries to install Graph.
> >
> > The cycle between these two is an interesting one.
> > boost/graph/breadth_first_search.hpp does:
> >
> > #ifdef BOOST_GRAPH_USE_MPI
> > #  include <boost/graph/distributed/breadth_first_search.hpp>
> > #endif
> >
> > at its end, and boost/graph/distributed/breadth_first_search.hpp does:
> >
> > #ifndef BOOST_GRAPH_USE_MPI
> > #error "Parallel BGL files should not be included unless
> > <boost/graph/use_mpi.hpp> has been included"
> > #endif
> >
> > #include <boost/graph/breadth_first_search.hpp>
> >
> > at its very start. So these headers include each other.
> >
> > One would naively think that only the parallel header should include the
> > normal one, but one is not well versed in graph library architectures,
> > so one might quite possibly be missing something, or a lot.
>
> I believe you are correct here. Boost Graph should not depend on Boost Graph
> Parallel in any situation. Boost Graph Parallel is a library end-users
> should be able to use as they choose and Boost Graph itself should be usable
> without ever bringing in the Parallel code.

I concur.

I worked with these two libraries a few years ago, and my recollection
is Boost Graph was implemented first and has no dependency on Boost
Graph Parallel. At least for my use cases, this was true.

Karen.
--
Karen Shaeffer                 The subconscious mind is driven by your deeply
Neuralscape Services           held beliefs -- not your deeply held desires.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Cycle between Graph and GraphParallel

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, 6 Oct 2018, Peter Dimov via Boost wrote:

> Currently we have a dependency cycle between `graph` and `graph_parallel`.
> It's not the only one, but it's notable with the fact that both libraries are
> buildable and we therefore can't ignore it as we can ignore cycles between
> header-only libraries that at release time become a single directory.
>
> In the particular, this impedes efforts to generate CMake config files. Under
> one scheme I'm currently working on, for instance, Boost.Python can't be
> installed because it tries to install Graph, which tries to install
> GraphParallel, which tries to install Graph.
>
> The cycle between these two is an interesting one.
> boost/graph/breadth_first_search.hpp does:
>
> #ifdef BOOST_GRAPH_USE_MPI
> #  include <boost/graph/distributed/breadth_first_search.hpp>
> #endif
>
> at its end, and boost/graph/distributed/breadth_first_search.hpp does:
>
> #ifndef BOOST_GRAPH_USE_MPI
> #error "Parallel BGL files should not be included unless
> <boost/graph/use_mpi.hpp> has been included"
> #endif
>
> #include <boost/graph/breadth_first_search.hpp>
>
> at its very start. So these headers include each other.
>
> One would naively think that only the parallel header should include the
> normal one, but one is not well versed in graph library architectures, so one
> might quite possibly be missing something, or a lot.
>
> Comments?

I don't know why you are calling this a dependency. The file declares the
sequential stuff, and if the parallel version is available/requested
(BOOST_GRAPH_USE_MPI) makes it available as well. So you don't need the
parallel version to use the sequential one.

--
Marc Glisse

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Cycle between Graph and GraphParallel

Boost - Dev mailing list
Marc Glisse wrote:
> On Sat, 6 Oct 2018, Peter Dimov via Boost wrote:
>
> > Currently we have a dependency cycle between `graph` and
> > `graph_parallel`.

...

> I don't know why you are calling this a dependency.

Boostdep is calling it a dependency, not me. I could hand-edit the
dependency file each time after it's generated, in principle, or even script
that, but I am not a fan of adding even more special cases to our process.

And in either case, when BOOST_GRAPH_USE_MPI is defined, both headers
_include each other_.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost