> On April 10, 2014, 7:44 p.m., Benjamin Hindman wrote: > > 3rdparty/Makefile.am, lines 73-75 > > <https://reviews.apache.org/r/20119/diff/3/?file=554542#file554542line73> > > > > This could just be my ignorance of autotools, but does this mean if > > someone does a 'make dist' after first doing a ./configure > > --with-leveldb=/path/to/prefix then we won't include leveldb.tar.gz in the > > distribution? It seems like we'd always want leveldb in the distribution > > such that someone else could download that distribution and run configure > > differently and things just work. > > Timothy St. Clair wrote: > That's *only-if* someone specifies --with-leveldb=/prefixloc, in that > case it's in the packagers court to decide. Which is arguably the correct > path, should they choose to build that way. > > Timothy St. Clair wrote: > So I sanity checked from multiple sources and all are in agreement. If > the builder/packager chooses to build against a prefix'd package then it's > their responsibility to ensure the 'specific version' of their dependency is > available either through package management or otherwise.
This makes sense to me from a packagers perspective, especially since in creating the package you can likely use different mechanisms to specify your dependencies. But this doesn't make a lot of sense to me for somebody creating a distribution (e.g., for the 0.19.0 release). What's even more bizarre to me is that someone that downloads a distribution created this way and runs './configure --enable-bundled' will not get an error but later when they run 'make' compilation will fail when certain dependencies (headers, libraries, etc) are not found. So I guess my question is, what do we stand to gain by doing it this way? Maybe there is something I'm totally missing? - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20119/#review40069 ----------------------------------------------------------- On April 11, 2014, 4:29 p.m., Timothy St. Clair wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/20119/ > ----------------------------------------------------------- > > (Updated April 11, 2014, 4:29 p.m.) > > > Review request for mesos and Benjamin Hindman. > > > Bugs: MESOS-1071 and MESOS-1168 > https://issues.apache.org/jira/browse/MESOS-1071 > https://issues.apache.org/jira/browse/MESOS-1168 > > > Repository: mesos-git > > > Description > ------- > > Allows preventing the use of bundled libraries in favor of preinstalled > versions, where possible. > > --disable-bundled generally switches from bundled to preinstalled libraries. > > If --disable-bundled is supplied or --with-leveldb[=DIR] was given but the > configuration phase could not locate the dependency, it stops with an error. > If --disable-bundled is not supplied and no --with-leveldb[=DIR] was given, > the bundled library is built and used (DEFAULT). > > NOTE: > 1. This review only implements this preinstalled library usage on LevelDB & > ZooKeeper. Subsequent review requests for other bundled libraries will follow > as soon as this implementation has been accepted. > > 2. This modification removed the old --without-installed-PACKAGE semantics, > as they conflict with well established --with-PACKAGE semantics > > > Diffs > ----- > > 3rdparty/Makefile.am 23ff1fa > configure.ac c1de6d7 > src/Makefile.am 95f133d > src/python/setup.py.in 02f00ef > > Diff: https://reviews.apache.org/r/20119/diff/ > > > Testing > ------- > > make check across all combinatoric incantations. > > > Thanks, > > Timothy St. Clair > >
