incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Diduck" <lancedid...@nyc.rr.com>
Subject RE: type_traits and other things
Date Tue, 11 Oct 2005 03:32:04 GMT
<< I'm not sure about these non-ASF copyrights. >>
Yes these are a pain in the (*|*) and before I do anything we'll go over a
cut. I have a friend who may be interested in helping in the legal area,
I'll try to remember to ask tomorrow. He is a NY Bar member who specializes
in software issues, and helped me a lot with getting my employer comfortable
in my involvement with ASF.

The copyright is largely like the all the STL implementations carrying the
HP license. It would be hard to get rid of the reference version license,
and after all, they did come up with the design. Most of the other stuff may
be doable, but in any case the licenses would be of the "no warranty" type,
and far less stringent that the Stallman variety licenses, i.e. no
copylefts.
In any case, any non-ASF license would make it non-deployable, and not much
use.
The commit then review would be very helpful, at least to a separate
"work-in-progress" area. Doing this for the Cygwin port would help too. I'm
finishing up some changes that I hope will be a differentiating point from
the boost implementation, and giving it a shot at work now -- no interface
or semantic changes, of course, just more options in the implementations
(like different ways of handling undefined behavior), and beefier tests.

Lance

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Wednesday, September 28, 2005 4:52 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: type_traits and other things

Lance Diduck wrote:
> On shared_ptr and type_traits -- I've requested to copyright release and
IP
> review from work, that could take a couple of weeks. I have most of
Sections
> 2 and 4. Most of this stuff will be crammed with various copyrights, from
> boost, a couple of books (notably Vandevoorde and Josuttiss), and other
> attributions to different contributors collected over the course of time.

I'm not sure about these non-ASF copyrights. AFAIK, the ASF frowns
on, or at least questions such things, even if they are compatible
with the Apache License. Our mentors will need to take a look at it
and give their yay or nay before we can use the code. It would be
easier to get rid of as much as you legally can.

> 
> The easiest way to separate them IMHO would be to have them in a working
> directory separate from the existing std stuff. This area would not follow
> the review then commit rules. The rule would only apply when the library
was
> voted for release, and then merged to 'tr1' or whatever it would be called
> upon vote. Then the rule applies.

Going the commit-then-review route sounds like a sensible approach for
new files. I believe some of the TR1 bits are mixed in with the existing
stuff so at least in some cases people will need to do both (touch the
existing headers in addition to the experimental ones). To isolate the
changes in the existing headers we'll need to guard them all with some
macro (such as _RWSTD_EXT_TR1). We might also want to consider creating
a separate branch for TR development.

> The Clearcase SCCS makes this easy, and I'll have to find out how to do
this
> with SVN.

My initial thought on the directory layout for the TR1 stuff is simply
to add

   include/tr1/   -- TR1 headers
   src/tr1/      -- TR1 sources

The thing to decide on will be the mechanism to enable the TR1 bits in
our builds. We could require that a macro be set in addition to adding
-Itr1 to the preprocessor options or require only that -Itr1 be before
any other -I options so that its headers are found before any existing
headers with the same name.

> We finished up a shared_ptr regression tester at work as well, tests
> shared_ptr but does no rely on the fact that the template is called
> shared_ptr. Allows testing of a number of implementations without changing
> the tester. Make "what-if" analysis far far easier.

We'll definitely need tests for all TR contributions. I'm still refining
the test driver but most of it is already in place. Whenever you have
a chance it would be great if you could take a look at it and post your
feedback.

Martin



Mime
View raw message