On 9/6/2015 7:13 PM, Richard Hipp wrote:
On 9/6/15, Scott Robison <sc...@casaderobison.com> wrote:
I was doing a little fossil hacking today and went to build it on my
freebsd box and it failed because the manifest was not present. Is there a
reason why we haven't created a manifest versionable setting? It seems like
an obvious one for the project to have.
Are there any projects (other than Fossil itself, and SQLite) that use it?
I use it in several of my non-toy, customer-facing projects. I do
embedded systems firmware, and often want to leave a marker in released
firmware for what checkin was used to build the release as shipped and
installed in a device.
I seem to re-invent that wheel a lot, and haven't settled on the perfect
solution, but without enabling the manifest the archived tarball of a
source snapshot would not be able to produce a bit-for-bit identical
copy of the firmware because it is no longer associated with an open
fossil repository. I assume that is the core reason it is used for the
fossil and SQLite projects as well.
If that restriction is not a concern, it is easy enough to parse the
output of fossil info, fossil changes, and fossil extra to get strings
that can be embedded in code.
(I look at changes and extra when building a shipment to help avoid
accidentally shipping something that has uncommitted changes. In at
least one project, I also made the a prominent message appear in the
device when built from uncommitted changes. Given the friction inherent
in the build, flash, play with the toy to test it, find a bug while
outside playing and try to remember what you just did to reproduce it
sort of development cycle, any defense against too fast a release is
useful.)
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
