[config][predef] Is it OK for boost.config to depend on boost.predef?

Beman Dawes

28 May 2014 28 May '14

1:50 p.m.

There is a config pull request outstanding that includes . If it was almost any library other than config, I'd apply this without a second thought. But Boost config is special in that if it breaks, virtually the whole of boost breaks. So it makes sense to be cautious about dependencies. Has there been any discussion about the relationship between Boost.config and Boost.predef? Even if we accept the patch, is the right header? It just forwards: #include #include #include #include #include #include #include The rationale for the pull request is a need in other Boost libraries to detect Windows platform variants like BOOST_PLAT_WINDOWS_DESKTOP andBOOST_PLAT_WINDOWS_RUNTIME. Boost.Predef does a nice job of that. But the only header strictly needed is . So the desired effect can be achieved several ways: 1) #include in the include/boost/config/platform/ headers. 2) #include in the include/boost/config/platform/ headers. 3) #include in the files that actually use the desired macros. 4) #include in the files that actually use the desired macros. If I had been writing the code myself, I probably would have selected option (4). What do others think? --Beman

Show replies by date

Rene Rivera

28 May 28 May

2:38 p.m.

On Wed, May 28, 2014 at 8:50 AM, Beman Dawes wrote:

...

There is a config pull request outstanding that includes .

If it was almost any library other than config, I'd apply this without a second thought. But Boost config is special in that if it breaks, virtually the whole of boost breaks. So it makes sense to be cautious about dependencies. Has there been any discussion about the relationship between Boost.config and Boost.predef?

There may have been some minor discussion some years ago when I first proposed Predef. But i don't remember one after that. My goal is to have Config depend on Predef. And eventually rewrite Config such that is does use any of the platform specific defs directly.

...

Even if we accept the patch, is the right header? It just

It's not the right header. Predef supports fine grain inclusion of its headers. So the desired effect can be achieved several ways:

...

1) #include in the include/boost/config/platform/ headers. 2) #include in the include/boost/config/platform/ headers. 3) #include in the files that actually use the desired macros. 4) #include in the files that actually use the desired macros.

5) #include #include

...

If I had been writing the code myself, I probably would have selected option (4). What do others think?

I would go with option (5) :-) Or a variation of that as needed. Note/Warning, I was not planning on merging Predef develop to master until after the next release (as the docs need to be updated and quickbook is giving me problems ATM). So whatever change that depends on those added defs will need to be postponed until after the next release. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

John Maddock

29 May 29 May

8:20 a.m.

New subject: [config][predef] Is it OK for boost.config to depend on boost.predef?

...

...
4) #include in the files that actually use the desired macros.

That seems like the correct solution to me: a file should include the headers documented to define the things it needs and not rely on implicit includes (even though through laziness we do that all the time!).

...

5) #include #include

...
If I had been writing the code myself, I probably would have selected option (4). What do others think?

I would go with option (5) :-) Or a variation of that as needed.

Note/Warning, I was not planning on merging Predef develop to master until after the next release (as the docs need to be updated and quickbook is giving me problems ATM). So whatever change that depends on those added defs will need to be postponed until after the next release.

That seems like a good reason not to create a dependency to predef, at least not yet, I'd like to be able to do one more merge of develop->master in Boost.Config before the next release. Cheers, John.

Beman Dawes

11:02 a.m.

On Thu, May 29, 2014 at 4:20 AM, John Maddock wrote:

...

4) #include in the files that actually use the

...
...
desired macros.

That seems like the correct solution to me: a file should include the headers documented to define the things it needs and not rely on implicit includes (even though through laziness we do that all the time!).

You are right, of course.

...

Note/Warning, I was not planning on merging Predef develop to master until

...
after the next release (as the docs need to be updated and quickbook is giving me problems ATM). So whatever change that depends on those added defs will need to be postponed until after the next release.

That seems like a good reason not to create a dependency to predef, at least not yet, I'd like to be able to do one more merge of develop->master in Boost.Config before the next release.

+1 --Beman

Beman Dawes

11:59 a.m.

On Wed, May 28, 2014 at 10:38 AM, Rene Rivera wrote:

...

Note/Warning, I was not planning on merging Predef develop to master until after the next release (as the docs need to be updated and quickbook is giving me problems ATM). So whatever change that depends on those added defs will need to be postponed until after the next release.

I'd prefer to see Predef go in the August release, even if the documentation is less than perfect. Otherwise we are going to have to figure out a temporary workaround to supply Windows platform details, and that is a pain. Also, Git says you merged the new version of to master on 9/9/13, and merged libs/predef develop to master on 1/2/14. What am I missing? --Beman

Daniel James

12:52 p.m.

On 29 May 2014 12:59, Beman Dawes wrote:

...

Also, Git says you merged the new version of to master on 9/9/13, and merged libs/predef develop to master on 1/2/14. What am I missing?

The predef master branch isn't a continuation of the subversion release branch, we switched to the original git branch a while ago, so the histories of the two repos aren't going to be in sync (this was agreed long before the git conversion, so no complaining please). Checkouts of old versions of the superproject will be, so if you want to look at historical versions, that's the place to look. This is actually the case in general as some modules have done fast-forward merges to master, so you can't tell when a change was merged to release, only when it was first committed.

Andrey Semashev

1:05 p.m.

On Thu, May 29, 2014 at 4:52 PM, Daniel James wrote:

...

On 29 May 2014 12:59, Beman Dawes wrote:

...
Also, Git says you merged the new version of to master on 9/9/13, and merged libs/predef develop to master on 1/2/14. What am I missing?

The predef master branch isn't a continuation of the subversion release branch, we switched to the original git branch a while ago, so the histories of the two repos aren't going to be in sync (this was agreed long before the git conversion, so no complaining please). Checkouts of old versions of the superproject will be, so if you want to look at historical versions, that's the place to look. This is actually the case in general as some modules have done fast-forward merges to master, so you can't tell when a change was merged to release, only when it was first committed.

I think there's misunderstanding. Rene said he didn't merge Predef to master but it is clearly there (and it should be since it was released in 1.55), and that was the source of confusion. Apparently he meant that he didn't merge some of the pending changes, so the questions are: - Is my interpretation correct? - Is the version of Boost.Predef in master usable (i.e. can be released in 1.56)? - Is the version of Boost.Predef in master suitable for Boost.Config needs? I.e. does it have the functionality Boost.Config needs and is that functionality stable?

Daniel James

2:23 p.m.

On 29 May 2014 14:05, Andrey Semashev wrote:

...

On Thu, May 29, 2014 at 4:52 PM, Daniel James wrote:

...
On 29 May 2014 12:59, Beman Dawes wrote:

...
Also, Git says you merged the new version of to master on 9/9/13, and merged libs/predef develop to master on 1/2/14. What am I missing?

The predef master branch isn't a continuation of the subversion release branch, we switched to the original git branch a while ago, so the histories of the two repos aren't going to be in sync (this was agreed long before the git conversion, so no complaining please). Checkouts of old versions of the superproject will be, so if you want to look at historical versions, that's the place to look. This is actually the case in general as some modules have done fast-forward merges to master, so you can't tell when a change was merged to release, only when it was first committed.

I think there's misunderstanding.

I was explaining why the history wrt. boost/detail/endian.hpp appears inconsistent, and was only responding to the part of the email that I quoted. I don't know anything about the current state of predef, so I wouldn't comment on that.

Beman Dawes

1:06 p.m.

On Thu, May 29, 2014 at 8:52 AM, Daniel James wrote:

...

On 29 May 2014 12:59, Beman Dawes wrote:

...
Also, Git says you merged the new version of to master on 9/9/13, and merged libs/predef develop to master on 1/2/14.

What

...
am I missing?

The predef master branch isn't a continuation of the subversion release branch, we switched to the original git branch a while ago, so the histories of the two repos aren't going to be in sync (this was agreed long before the git conversion, so no complaining please). Checkouts of old versions of the superproject will be, so if you want to look at historical versions, that's the place to look. This is actually the case in general as some modules have done fast-forward merges to master, so you can't tell when a change was merged to release, only when it was first committed.

Ah! Thanks! So the only issue is predef/include/boost/predef/platform.h and the four newpredef/include/boost/predef/platform/windows_* files. These are the ones I would like to see merged to master asap. --Beman

Rene Rivera

2:28 p.m.

On Thu, May 29, 2014 at 8:06 AM, Beman Dawes wrote:

...

On Thu, May 29, 2014 at 8:52 AM, Daniel James wrote:

...
On 29 May 2014 12:59, Beman Dawes wrote:

...
Also, Git says you merged the new version of

to

...
master on 9/9/13, and merged libs/predef develop to master on 1/2/14. What am I missing?

The predef master branch isn't a continuation of the subversion release branch, we switched to the original git branch a while ago, so the histories of the two repos aren't going to be in sync (this was agreed long before the git conversion, so no complaining please). Checkouts of old versions of the superproject will be, so if you want to look at historical versions, that's the place to look. This is actually the case in general as some modules have done fast-forward merges to master, so you can't tell when a change was merged to release, only when it was first committed.

Ah! Thanks!

So the only issue is predef/include/boost/predef/platform.h and the four newpredef/include/boost/predef/platform/windows_* files. These are the ones I would like to see merged to master asap.

I would have to merge the entire develop branch over which has many changes. But I will try and work on it ASAP. I'll just have to work around the quickbook errors I'm getting. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

John Maddock

3:32 p.m.

New subject: [config][predef] Is it OK for boost.config to depend on boost.predef?

...

I would have to merge the entire develop branch over which has many changes. But I will try and work on it ASAP. I'll just have to work around the quickbook errors I'm getting.

Docs build cleanly for me in develop, what am I missing? Can I help? John.

Rene Rivera

3:35 p.m.

On Thu, May 29, 2014 at 10:32 AM, John Maddock wrote:

...

I would have to merge the entire develop branch over which has many

...
changes. But I will try and work on it ASAP. I'll just have to work around the quickbook errors I'm getting.

Docs build cleanly for me in develop, what am I missing? Can I help?

Hmm.. I'll have to look then. I tried some time ago and had failures. Will try again. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3834

Age (days ago)

3835

Last active (days ago)

List overview

Download

11 comments

5 participants

participants (5)

Andrey Semashev
Beman Dawes
Daniel James
John Maddock
Rene Rivera