[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [modularization] Extract xml_archive from serialization
From:       Stephen Kelly <hello () steveire ! com>
Date:       2014-09-17 22:37:38
Message-ID: lvd2f8$rj3$1 () ger ! gmane ! org
[Download RAW message or body]

Robert Ramey wrote:

> Stephen Kelly-2 wrote
>> Is this "at the expense of everyone who wants to ship datetime with
>> support
>> for serialization in the package"? Is that 'non-obvious' too? Is this a
>> net-
>> positive?
> 
> I think its a much smaller number of people.

We can both think lots of things. 

I think there are more similarities in consequences of your plan the more 
you describe it.

> anyone who explicitly includes date-time/serialization.hpp will know that
> he has to ship the data-time-serialization.dll.

Amazing. 

What will someone who explicitly includes archive/basic_xml_archive.hpp 
possibly think he has to ship?

> others shipping the serialization dlls now have to decide whether
> to include wide-characters or not.  Now they would have to start
> thinking about whether to include support for xml_archive or not.

... or date-time-serialization or not.

> This suggests that the serialization library should create a set of
> dlls with names like
> serialization-core.dll
> serialization-text_archive.dll
> serialization-xml_archive.dll
> ...
> 
> To avoid xml_archive being a special case which is quite confusing.

I don't think it's confusing. It's just a change.

> Note that none of the above requires separate git repositories or
> include hierarchies.  Moving the files around doesn't remove dependencies,
> it diminishes the presence of false dependencies in the dependency
> tracking tool.

The dependencies are not false if they refer to dependencies between git 
repos, or between modularized release tarballs (if that's a goal).

>>> Now
>>> the original app user above has only what he wants and is
>>> not dependent upon boost serialization.  Yet other users
>>> of the serialization library have what they want - serialization
>>> all in one place.
>> 
>> You just created a separate thing to (presumably separately) download.
>> What's the 'all in one place' part?
> 
> Hmmm - in the current scheme - we're creating multiple libraries or dlls
> within one git repo.  That's what we do now.
> 
> In your scheme - we also create more libraries/dlls but the the source
> is organized in a separate git repo.  That's the difference.

You write as-if you think git is the only/primary way to use boost.

Are releases irrelevant? And release tarballs? Would your date-time-
serialization library be in a separate release tarball?

>> Isn't auto-link a VC++ only thing? Trying to assess the veracity of the
>> 'don't have to do anything special' claim.
> 
> Its a VC thing and also a Borland thing - though I guess that's not
> relevant
> any more.  I guess its not a gcc or clang thing so I see now that this is
> a
> red herring.

Yes.

>>> Do you mean creating a separate module at the git level?
>> 
>> Yes. Locally I've moved the deleted files below into a new repo,
>> xml_archive.git

> Hmmm - this looks like its on your local machine.

Yes.

> Do you plan to commit this? 

I'm not that rude! :)

I wrote a script in July to automate this split (to be immune to merge 
conflicts etc). I started this thread to get support for going ahead with 
doing the split in develop.

> Do you have the authority to do so?

No.

Thanks,

Steve.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]