Start separating mandatory source?
Since we just had a release, should be re-visit moving all the mandatory source code into a separate directory together? For the newbies, this means changing the BOOST_ROOT . libs .. date_time ... src .. graph ... src into something like BOOST_ROOT . src .. date_time .. graph Right now, using mandatory source files means scrambling into a lot of directories figuring out what to add. There is stuff like Boost-Build, but it doesn't work for everyone, and I feel that it's a "cute" overkill solution. No matter the plan there are some caveats: 1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.) Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build. If some source needs to be in a DLL, then start a sub-project. (If you don't need a library at all, then exclude it from the project to save compile time. The linker will tell you, by choking, if you went too far.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
Since we just had a release, should be re-visit moving all the mandatory source code into a separate directory together? For the newbies, this means changing the
BOOST_ROOT . libs .. date_time ... src .. graph ... src
into something like
BOOST_ROOT . src .. date_time .. graph
Right now, using mandatory source files means scrambling into a lot of directories figuring out what to add. There is stuff like Boost-Build, but it doesn't work for everyone, and I feel that it's a "cute" overkill solution. No matter the plan there are some caveats:
1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.)
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms. Not to mention that the test library has several (I think) source files containing main() and you can't just link them all together indiscriminately. Whatever you think of Boost.Build, I don't see how underkill can work, and I don't see how libs/xxx/src/... is much worse than src/xxx/... -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Daryle Walker <darylew@hotmail.com> writes:
No matter the plan there are some caveats:
1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.)
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms.
OK as far as I know.
Not to mention that the test library has several (I think) source files containing main() and you can't just link them all together indiscriminately.
Um, caveat #2 above? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
It isn't true. Some libraries need specific compiler/linker options on specific platforms.
OK as far as I know.
I don't know what that is supposed to mean. I know what I say is true because I am the author of one such library.
Not to mention that the test library has several (I think) source files containing main() and you can't just link them all together indiscriminately.
Um, caveat #2 above?
Oops, sorry. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
It isn't true. Some libraries need specific compiler/linker options on specific platforms.
OK as far as I know.
I don't know what that is supposed to mean. I know what I say is true because I am the author of one such library.
That's supposed to mean that I took you at your word. I had no contrary information, so I wasn't questioning that part of your argument. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On 8/19/05 10:31 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
[SNIP]
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms. [SNIP]
Maybe we should consider that (and the separate DLL thing) to be a bug?
Whatever you think of Boost.Build, I don't see how underkill can work, and I don't see how libs/xxx/src/... is much worse than src/xxx/...
If the source files are in one location, it's easier to find out if a *.hpp file has corresponding source. The user otherwise has to dig through a lot of directories and/or documentation. (The latter requires figuring out which documentation corresponds to a header file.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 8/19/05 10:31 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
[SNIP]
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms. [SNIP]
Maybe we should consider that (and the separate DLL thing) to be a bug?
So you're giving me a choice between admitting there's a bug in my build specification or having my library fail to build on some platform?
Whatever you think of Boost.Build, I don't see how underkill can work, and I don't see how libs/xxx/src/... is much worse than src/xxx/...
If the source files are in one location, it's easier to find out if a *.hpp file has corresponding source. The user otherwise has to dig through a lot of directories and/or documentation.
Which source file corresponds to a header is not something that should usually be of concern to our users, and even when it is, it isn't worth reorganizing the Boost project structure for. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 8/22/05 9:12 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
On 8/19/05 10:31 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
[SNIP]
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms. [SNIP]
Maybe we should consider that (and the separate DLL thing) to be a bug?
So you're giving me a choice between admitting there's a bug in my build specification or having my library fail to build on some platform?
I didn't know about the specific-options requirement. I feel we should strive for our code to work without tweaks (but still be compatible with tweaks that the user may add). I guess there's no way around it. What build specification are you referring to?
Whatever you think of Boost.Build, I don't see how underkill can work, and I don't see how libs/xxx/src/... is much worse than src/xxx/...
If the source files are in one location, it's easier to find out if a *.hpp file has corresponding source. The user otherwise has to dig through a lot of directories and/or documentation.
Which source file corresponds to a header is not something that should usually be of concern to our users, and even when it is, it isn't worth reorganizing the Boost project structure for.
It is a concern if the user adds Boost sources to his/her project file directly (instead of linking to a library pre-built by our scripts). I think if we _require_ Bjam, Boost.Build, or similar to use Boost, then we have failed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 8/22/05 9:12 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
On 8/19/05 10:31 AM, "David Abrahams" <dave@boost-consulting.com> wrote:
Daryle Walker <darylew@hotmail.com> writes:
[SNIP]
Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build.
It isn't true. Some libraries need specific compiler/linker options on specific platforms. [SNIP]
Maybe we should consider that (and the separate DLL thing) to be a bug?
What's the "separate DLL thing" anyway?
So you're giving me a choice between admitting there's a bug in my build specification or having my library fail to build on some platform?
I didn't know about the specific-options requirement. I feel we should strive for our code to work without tweaks (but still be compatible with tweaks that the user may add). I guess there's no way around it.
What build specification are you referring to?
Boost.Python's, for example.
Whatever you think of Boost.Build, I don't see how underkill can work, and I don't see how libs/xxx/src/... is much worse than src/xxx/...
If the source files are in one location, it's easier to find out if a *.hpp file has corresponding source. The user otherwise has to dig through a lot of directories and/or documentation.
Which source file corresponds to a header is not something that should usually be of concern to our users, and even when it is, it isn't worth reorganizing the Boost project structure for.
It is a concern if the user adds Boost sources to his/her project file directly (instead of linking to a library pre-built by our scripts).
No. Being able to find the sources that belong to a library is a concern, but then that's easy: libs/library-name/src/*
I think if we _require_ Bjam, Boost.Build, or similar to use Boost, then we have failed.
We don't require it, whether or not the sources are reorganized. -- Dave Abrahams Boost Consulting www.boost-consulting.com
It is a concern if the user adds Boost sources to his/her project file directly (instead of linking to a library pre-built by our scripts). I think if we _require_ Bjam, Boost.Build, or similar to use Boost, then we have failed.
Sure, but don't forget that: ls libs/*/src/*.cpp will pretty much find all the source files, Oh, and which libraries have separate source is documented in the getting started guide as well. John.
participants (4)
-
Daryle Walker -
David Abrahams -
John Maddock -
Rob Stewart