On Mon, Apr 15, 2013 at 7:22 PM, Greg Troxel <[email protected]> wrote:
>
> Richard Shaw <[email protected]> writes:
>
> > Speaking of which...
> > Do we really need to know the svn rev?
> > Should a svn export not be preferred over a full checkout? (At least for
> > real releases)
>
> In general, I think it's good for the VCS revision tag (svn revision,
> git sha1, etc) to be baked into the binaries somehow. But I don't think
> it's critical.
automake has a notion where typically generated files are not checked
> in, and there is a 'make dist' process to build a release tarball from a
> VCS checkout (typically tagged). I think this makes sense separately
> From using automake and should continue; checking in generated files is
> awkward. It may be that with a 100% cmake world there are fewer
> generated files.
>
I'm assuming when you say to not check in typically generated files you
don't mean configure or config.h, right? I'm the Fedora packager for
several autoconf type projects but I've never had to run autoheader before
to get a build completed.
If that's the case and if the svn revision something that we really want to
capture, is there a way to dump that into config.h during/prior to the
export? That way the svn files don't make it into the source archive.
> Looking through the resultant config.h after running autoheader I see a
> > bunch of HAVE_.... this and that, but grepping through the code it
> doesn't
> > look like we're actually doing anything with the definitions. I would
> > expect some sort of conditionals based on the system and libraries
> > available...
>
> > Do we really need all these definitions? Or do we just need to make sure
> > those function/headers are available?
>
> A long time ago, systems varied much more wildly than they do now. So
> it was necessary to test for many features. This was far better than
> checking for a particular operating system, because the build system
> would function on a new system, or on a new version of a system, by
> detecting features rather than having the capabilities of a particular
> OS version baked into the configure system.
>
I'm already testing for most of them, and I've even started on the cmake
version of config.h, it's actually pretty easy now that I've looked into
it, but if a function or header is required, meaning we don't provide a
workaround in case it's not available, then my vote would be to test
for existence and error out if it's not available and skip putting the
result in config.h.
I would suggest that for each feature test in config.h, someone see if
> it's ever tested in the code, and if not remove it. The other thing to
> do is to look for "#ifdef OS" and try to remove that in favor of a
> feature test.
> Sometimes though, one has to say "on linux, the way you do foo is bar,
> and on *BSD it's baz", generally for things that are not specified
> by POSIX.
>
Most of what I found seems to be doing different things based on the type
of compiler more so than based on the OS so it looks pretty good there. I
did see any HAVE_... is any #ifdef's when grepping through the source.
Thanks,
Richard
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
