Standardization of build
Hi, I noticed that the build of some projects (filesystem, date_time, signals) differs from the build of the thread, regex and python libraries in that they they do not include a bin-stage and that debug and release versions have the same name. It would be nice if this could be standardized somehow (especially that debug and release versions should have different names). /Johannes
I noticed that the build of some projects (filesystem, date_time, signals) differs from the build of the thread, regex and python libraries in that they they do not include a bin-stage and that debug and release versions have the same name.
It would be nice if this could be standardized somehow (especially that debug and release versions should have different names).
This should probably be considered a bug in the Jamfiles for filesystem, date_time, and signals. And you are absolutely right that we should standardize this. Doug
This should probably be considered a bug in the Jamfiles for filesystem, date_time, and signals. And you are absolutely right that we should standardize this.
If we do, can we use the existing regex naming scheme? It covers most of the bases IMO (debug/release, threaded/single, dynamic/static runtimes), and the automatic library selection code is almost generic as well if the other libs want to use it. We really should bin-stage these into a common central directory as well BTW. John.
This should probably be considered a bug in the Jamfiles for filesystem, date_time, and signals. And you are absolutely right that we should standardize this.
If we do, can we use the existing regex naming scheme? It covers most of the bases IMO (debug/release, threaded/single, dynamic/static runtimes), and the automatic library selection code is almost generic as well if the other libs want to use it.
Absolutely. I'll switch Signals over once I get around to fixing it for the new iterator adaptors.
We really should bin-stage these into a common central directory as well BTW.
John.
Another installation issue, which we seem to be avoiding at all cost :) But I agree, of course. Doug
Absolutely. I'll switch Signals over once I get around to fixing it for the new iterator adaptors.
Should be done now. I copied John's code verbatim, so I think it should work :) I'm rather ignorant of these Microsoftisms. Doug
At 01:03 AM 7/16/2003, Douglas Gregor wrote:
Absolutely. I'll switch Signals over once I get around to fixing it for the new iterator adaptors.
Should be done now. I copied John's code verbatim, so I think it should work :) I'm rather ignorant of these Microsoftisms.
Ouch! I just looked at the changes Doug made to the signals Jamfile. The changes created a maintenance nightmare. Before the changes, the Jamfile was so simple and declarative that anyone can maintain it. The maintainer don't really need to know anything about bjam or Boost.Build to understand it. The change dramatically increased the size and complexity. Now only a Boost.Build expert could even think of making a change. It has become unreadable except to those with considerable training. Furthermore, the same code will be duplicated in multiple libraries. When the inevitable changes are needed, they will be applied to some libraries but not others. The copied code will begin to diverge. It doesn't get any worse than that. All that complexity needs to be factored out so that: 1) Jamfiles needing the functionality don't have to do anything more complex than the original dll and lib invocations. 2) Maintenance to the "stage" code can be performed at a single location. The terminology could use some help too. What is a "stage"? That isn't a term familiar to most developers. What problem is being solved? If it is some really important problem, why do "dll" and "lib" even work without also solving whatever problem "stage" solves? I'm sorry to be so grouchy about this, but I think we need to step back and figure out a cleaner overall approach before we start changing Jamfiles. --Beman
Beman Dawes
At 01:03 AM 7/16/2003, Douglas Gregor wrote:
Absolutely. I'll switch Signals over once I get around to fixing it for the new iterator adaptors.
Should be done now. I copied John's code verbatim, so I think it should work :) I'm rather ignorant of these Microsoftisms.
Ouch! I just looked at the changes Doug made to the signals Jamfile.
The changes created a maintenance nightmare. Before the changes, the Jamfile was so simple and declarative that anyone can maintain it. The maintainer don't really need to know anything about bjam or Boost.Build to understand it.
The change dramatically increased the size and complexity. Now only a Boost.Build expert could even think of making a change. It has become unreadable except to those with considerable training.
Furthermore, the same code will be duplicated in multiple libraries. When the inevitable changes are needed, they will be applied to some libraries but not others. The copied code will begin to diverge. It doesn't get any worse than that.
All that complexity needs to be factored out so that:
1) Jamfiles needing the functionality don't have to do anything more complex than the original dll and lib invocations.
2) Maintenance to the "stage" code can be performed at a single location.
The terminology could use some help too. What is a "stage"? That isn't a term familiar to most developers. What problem is being solved? If it is some really important problem, why do "dll" and "lib" even work without also solving whatever problem "stage" solves?
I'm sorry to be so grouchy about this, but I think we need to step back and figure out a cleaner overall approach before we start changing Jamfiles.
Agreed. And why are we having this discussion on the boost.users list? -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 11:53 AM 7/16/2003, David Abrahams wrote:
Agreed. And why are we having this discussion on the boost.users list?
My mistake. I was replying to something on the users list, but it clearly is a jamboost list topic. Let's move the discussion there. --Beman
participants (5)
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
Johannes Strömberg -
John Maddock