[apparmor] [PATCH 4/6] libapparmor: Check for podchecker during configure stage

[Tyler Hicks]

On 2014-11-17 14:33:38, Steve Beattie wrote:
> On Mon, Nov 17, 2014 at 03:05:19PM -0600, Tyler Hicks wrote:
> > Fail the configure stage if podchecker is not available since man page
> > generation always happens.
> 
> I think I disagree with this patch and the first patch. The minimal
> bit of userspace tools you need to get apparmor going in a limited
> environment are the libapparmor C library and the parser. I grant
> that we don't necessarily make it straightforward to build only these
> things, but requiring that some portion of perl be available at build
> time feels wrong to me.
> 
> That said, I realize we already require pod2man as part of the
> libapparmor build; that check should probably also be conditional on
> having perl available as well.
> 
> But I'm not in any way knowledgeable about bringing up embedded or
> otherwise limited environments, so maybe expecting that people have
> access to perl/pod2man/podchecker is reasonable. We have tried to fix
> problems that occurred when cross-compiling for embedded environments,
> and I think we should continue to support (and improve our support for)
> such environments.

This patch set was an attempt at fixing up docs and build scripts
without changing behavior that creates work for packagers.

  --enable-man-pages      generate man pages [default=yes]

Man page generation will be enabled by default. The PROG_POD2MAN and
PROG_PODCHECKER checks will only occur when man page generation is
enabled.

This would allow us to keep current behavior (creating no new work for
packagers) and allow folks building libapparmor and apparmor_parser for
embedded systems to do so without needed Perl.

Whaddya think?

Tyler

> 
> I wouldn't mind if we made --with-python a default setting and
> then supported --without-python (or --no-with-python or whatever
> the configure idiom is for stuff like that). Perhaps similarly for
> --with-perl, too, though it's pretty clear going forward the perl
> bindings to libapparmor are going to be less well-exercised than the
> python bindings. And it's perhaps the case that I'm conflating 'have
> perl' with 'build the perl bindings', so there's that consideration,
> too.
> 
> And, it was mentioned that --with-or-without-perl doesn't apply across
> the rest of the tree; that's true mostly out of a resistance to use
> autotools for the rest of the tree, though I do have a TODO task
> to look at resurrecting Kees' patch for that, and perhaps compare
> with what cmake provides. There are a lot of times, however, where
> we do things that feel like fitting square pegs into round autotools
> holes, particularly around tests and building against multiple python
> versions. A lot of automake's support for tests seems to come down
> to 'we'll run whatever single test script you want', and finding
> out things like 'where the libapparmor python binding library build
> ended up, so that I can point test scripts at it' don't seem to be
> easily discoverable.
> 
> -- 
> Steve Beattie
> <sbeattie at ubuntu.com>
> http://NxNW.org/~steve/



> -- 
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20141117/0141773f/attachment.pgp>