third_party (ex-lib_3p) now ready for review.
jelmer at samba.org
Wed Jul 23 10:48:31 MDT 2014
On 23 July 2014 17:20:31 BST, Ira Cooper <ira at samba.org> wrote:
>On Wed, Jul 23, 2014 at 6:52 AM, Jelmer Vernooij <jelmer at samba.org>
>> On Wed, Jul 23, 2014 at 01:22:46AM -0700, Ira Cooper wrote:
>> > The functionality of the patch as far as a "user" is concerned is
>> > same. But it has been refactored underneath so it has less code
>> > duplication, and it is prepared for the day when we want to change
>> > of the third_party directory. (While I haven't plumbed it into
>> > one could.)
>> > The patchset itself has been broken out into smaller more
>> > patches.
>> > If you have comments on how to make it better, I'm all ears.
>> > The main thing, you will find me strongly opposed to changing is
>> > commit, removing the libraries, hopefully reading the popt commit
>> > you understand why, along with all the discussions along the way.
>> > I encourage you to see this as a "final draft". (Or RC1.) I do
>> > is much more ready to go than when I started, thank you for the
>> > comments! They truly did prove useful.
>> > Trees for review:
>> > Samba:
>> > Third party git tree:
>> > http://git.samba.org/?p=ira/third_party.git;a=summary
>> Comments, in random order:
>> Yay for splitting these out!
>> How are we going to keep the copy of third_party on the build farm up
>> to date?
>clone and pull the third_party repo is the easiest way.
There is no git on the build farm hosts, just rsync. This change should be accompanied by a change to the build farm to manage the third party repo.
>Checks for specific libraries don't belong under buildtools/wafsamba/,
>> which is our set of support libraries on top of waf. Please add
>> these checks in wscript or wscript_third_party or something
>> like that.
>I wasn't a fan of it either... but adding the changes to wscript is
>ugly and stops us from reusing them properly.
I doubt it would be that much code. Zlib is only used by samba itself. For the others, we can just use pkg gonfig. Also, we'll have to do this eventually anyway when we split these libraries off from the main samba repo.
More information about the samba-technical