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.