It's really nice to have the SVN rev in the application, as it gives users some
way to connect what they have to a source code version. In addition, I think
that David Rowe originally used the SVN rev to enable the software to indicate
if it was obsolete. However, I think that a binary release version or binary
build date is better for this. Both the executable and the file name of the
package generated by cpack should contain this. The goal is for the software to
be able to look in files.freedv.org and to determine if there is a newer
version available. It can then offer to download and install it; That will help
to keep everybody talking with our latest protocol version. We are rather far
from wanting to cast the modems or codec in concrete at this time - there is
too much potential for improvement, and everybody loves to get a free upgrade.
Thanks
Bruce
Richard Shaw <[email protected]> wrote:
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------------------------------------------------------------------------------
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
