On 08/23/2017 05:45 PM, Jon Loeliger wrote:
On Wed, Aug 23, 2017 at 2:25 PM, Dave Wallace <dwallac...@gmail.com> wrote:
IMO, "in-tree" .vs. "out-of-tree" really boils down to decoupling the app's
"Makefile.am" the rest of the vpp autotools structure/configuration. For
example, I ran into the same issue with
.../vppsb/vcl-ldpreload/src/Makefile.am (which is literally 'out-of-tree')
in the case where "VPP_DIR" is specified. However, the vcl-ldpreload build
would work the same if it was moved somewhere under vpp without integrating
it into .../vpp/src/Makefile.am -- thus it would equally be "out-of-tree"
even though it was stored in the vpp repo.
For lack of exposure to much of that, I'm sure some of the subtlety
of that is lost on me still.
There are some other test apps in .../vpp/src/uri, which could be migrated
there as well if we want to consolidate all apps under one directory.
Personally I think this makes sense.
All the 'test apps' under one directory makes loads of sense.
Currently these are "noinst_PROGRAMS" in .../vpp/src/uri.am. To build them
for testing, "s/noinst_PROGRAMS/bin_PROGRAMS/g" in uri.am, then rebuild --
which does build them 'in-tree' (i.e. using the vpp autotools
structure/configuration) --> the resulting binary executable files land in
.../vpp/build-root/install-vpp*-native/vpp/bin.
Hrm. We don't want to pollute the install with non-real binaries and
random test apps. (Is that what you said would happen here?)
Exactly. This is why uri.am currently has these test apps defined as
"noinst_PROGRAMS".
In any case, I think that it is entirely possible to implement your proposal
in such a way as to ensure that we can close the test escape that was the
impetus for your proposal.
That would be fabulous. This is the third or fourth time I've been
caught by it.
You bet.
My recommendation is to consolidate test
applications in the same location in the process, in which case I think
.../vpp/extras/apps is a better location than either .../vpp/make/test/c or
.../vpp/src/apps
I'm happy to have it anywhere that makes sense.
Extra happy if it ends up as part of a 'make test', 'make verify' or some
other pre-patch-acceptance criteria.
I sent in a patch, https://gerrit.fd.io/r/#/c/8189/ , that demos what would
be my intent with a 'make test-c-build'. It isn't currently wired into the
'make test' effort, but it could be readily.
Feel free to nix this patch, of course, but I'm not really sure where
or how to get an equivalent test into the ..extras/apps approach yet.
Cool. Give me a few days, and I'll revise this patch to consolidate the
test apps and integrate the 'make test-c-build' validation into 'make
verify'.
-daw-
Thanks,
-daw-
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
