[Bug 227309] Review Request: seom - Desktop video capture and playback utility

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: seom - Desktop video capture and playback utility


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227309





------- Additional Comments From jwilson at redhat.com  2007-02-08 16:49 EST -------
(In reply to comment #14)
> will do ... I'll drop you an email as soon as a new tarball is available.

Excellent, thank you.

> > For Fedora packages, libtool archives and static libs are forbidden, so it was
> > solely for the benefit of the package. I'll use a patch that doesn't nuke that,
> > and will instead remove the file from within the spec.
> 
> I would actually love to drop libtool, but it's a nice tool that adds '-fPIC'
> when needed (and other arch-dependent flags). But other than that, I find it
> horrible (what are these libtool archives for anyway? The compiler doesn't need
> them when linking against the library, right?).

I must admit to knowing very little about libtool or ways to replace it...

> > Other notes on the patch I'm using:
> > - splitting CFLAGS and EXTRA_CFLAGS makes packaging much easier. Fedora has a
> > standard set of CFLAGS that are supposed to be used on all packages, so
> > splitting off the -std=c99 bit into EXTRA_CFLAGS makes life easier, since its
> > required, but not part of the standard Fedora CFLAGS.
> 
> What about 'CFLAGS += ...' in the Makefile and a configure option --cflags,
> would that work for you?

I think a CFLAGS += might work, but the preferred way to get our CFLAGS into a
build is via an export, preferrably the one done by the %configure macro (which
also passes in libdir, bindir, sbindir, etc. info, which is part of why I was
dropping the additional *DIR bits into the Makefile).

> > - some of the added $(*DIR) bits are for convenience more than anything, but are
> > fairly standard.
> 
> One thing that still bothers be is my use of LIBDIR. I know it's non-standard,
> but I find it much more convenient when cross-compiling, because I only have to
> set LIBDIR='lib' or 'lib32' and not LIBDIR='$PREFIX/lib'. I also don't really
> see a use in installing the libs, apps and headers each into a different prefix.

Nah, we'd never install those bits in different prefixes either. This again goes
back to the %configure macro, which passes in a full path for LIBDIR. We never
touch LIB though, so I added that to add support for doing essentially what
you're doing w/LIBDIR at the moment. I could be missing something, but I though
that change would still allow you to build and install as you have been by
passing LIB='lib' or 'lib32'.

> I'm hard to convince, I admit, but my decisions are rarely set in stone, so I'm
> sure if you give me strong, good reasons I may change my use of LIBDIR ;)

Hope the above helped... :)

> > - you've got lots of extraneous slashes -- $(DESTDIR)/$(PREFIX) works out to
> > /somewhere//usr -- so I nuke all those.
> 
> Yeah, I noticed that, too, but i don't care because it's just a cosmetic change,
> or isn't it?

Mostly cosmetic, but also the right thing to do. :)


(In reply to comment #15)
> Just a question:
> 
> Should I wait this review until a new tarball is released?

Might as well.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.