Ben Pfaff <[email protected]> writes: > On Wed, Aug 02, 2017 at 05:25:36PM -0400, Aaron Conole wrote: >> Ben Pfaff <[email protected]> writes: >> >> > On Tue, Aug 01, 2017 at 06:05:40PM -0400, Aaron Conole wrote: >> >> When intermediary files are generated, the destination directory is >> >> assumed >> >> to exist. This has worked so far because most files are built prior to >> >> the dist-packaging step. However, any files which require rebuild after >> >> the packaging step may end up in failure if the output directory is not >> >> available. This commit adds a 'mkdir -p' before generating the output >> >> files. >> >> >> >> Signed-off-by: Aaron Conole <[email protected]> >> > >> > Thanks for working on the makefiles. >> > >> > What's an example of a file for which this makes a difference? I'm >> > having trouble understanding when this helps. >> >> Thanks for reviewing, Ben! >> >> The next patch in the series adds an example of this. I should have put >> that into the commit message as well. >> >> I'll go over the effect I observed, and maybe there's a better way to do >> it: >> >> 1. I added a 'preprocessor' to be able to have dpdk vs. non-dpdk >> functionality in generated files (ex: the vswitchd service file) >> >> 2. I execute `./configure --with-dpdk` and observe that the correct >> lines are included. So far so good. >> >> 3. I completely clean the tree, and do a `./configure` without >> specifying dpdk. The lines are not included, and still so far so >> good. >> >> 4. I use the resulting distribution (made with make dist) to build, >> doing `./configure --with-dpdk`. Now, I would think the file should >> have the correct lines included, but it does not. >> >> To resolve this, I tried adding the generated file as BUILT_SOURCES, but >> experienced errors when doing a `make distcheck`, since the $(srcdir) >> directory is read only. So, I implemented the approach where I added >> $(builddir)/config.status which would behave as I expect, but for the >> fact that the sed will do a redirect into a subdirectory that isn't >> created. >> >> I'm sure a better way could exist, but I don't know it. >> >> I guess that's a long-winded (apologies) way of saying there are >> currently no examples in tree - this commit adds one. > > I think that the root of the problem here is that we're distributing a > generated file, and it's made worse because that generated file depends > on the build-time configuration. That's a recipe for Autoconf/Automake > hell. > > Ideally, we'd stop distributing a generated file entirely. It's a > little complicated for packaging because we want to fill in part of the > packaging based on what's in OVS, but the straightforward way to do that > is to generate the packaging as part of the OVS build, but the OVS build > is what the packaging is supposed to do anyway. (Frankly I wish that > OVS didn't come with its own packaging--that would solve lots of > problems.) > > What if the spec files themselves did the editing of the service file, > instead of doing it from OVS? That would solve this particular problem > because we wouldn't need to have a generated file in the OVS tree (just > the source file).
I could try that. It would probably shrink this series a bit, so that's an added benefit. I'll see what I can cook up. -Aaron _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
