mailing list of musl libc
 help / color / mirror / code / Atom feed
* Storing version information in libc.so
@ 2013-11-27  5:48 Rich Felker
  2013-11-30 21:42 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: Rich Felker @ 2013-11-27  5:48 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

Hi,

The main agenda item I have left for the 0.9.15 release is making it
so libc.so can print its own version number. I'm attaching the
proposed build script that will generate version.c for comments on any
problems it might have or improvements to make.

At present, I have the script setup to generate a function which
returns the version string. This is in contrast to the other obvious
implementations, which would be a macro or an extern array object. The
macro is inappropriate because I don't want a large file like
dynlink.c to be recompiled each time the version changes (which, with
git, happens on each commit). The extern array is obviously nicer
looking than the function, but at the point where it needs to be used
in dynlink.c, relocations have not been performed and thus it's not
accessible. Arguably this should just be "fixed", since operating
without relocations for "usage" or "ldd" output is moderately hackish
anyway.

As for the build system, the proposed rule for generating version.c
is this:

src/internal/version.c: VERSION $(wildcard .git .git/*)
	sh tools/version.sh > $@

The use of $(wildcard) should handle the case where .git does not
exist (release tarballs) and avoids gratuitous dependency on git
internals.

FYI for anyone who doesn't want to actually try running the proposed
version.sh, the output it's producing looks like:

- "0.9.14-git-79-ga663c93" (with git command available)
- "0.9.14-git-unknown" (with .git present but no git command)
- "0.9.14" (with no .git)

Rich

[-- Attachment #2: version.sh --]
[-- Type: application/x-sh, Size: 346 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Storing version information in libc.so
  2013-11-27  5:48 Storing version information in libc.so Rich Felker
@ 2013-11-30 21:42 ` Rich Felker
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2013-11-30 21:42 UTC (permalink / raw)
  To: musl

On Wed, Nov 27, 2013 at 12:48:06AM -0500, Rich Felker wrote:
> As for the build system, the proposed rule for generating version.c
> is this:
> 
> src/internal/version.c: VERSION $(wildcard .git .git/*)
> 	sh tools/version.sh > $@

I think I'm going to replace this with:

src/internal/version.c: src/internal/version.h

and have version.h be the generated file, containing just:

#define VERSION "..."

This gives more flexibility to modify the mechanisms/linkage of stuff
in version.c without having to edit a script, and makes the version.sh
script much more generic. It also avoids the need to hard-code a
generated .c file into the SRCS/OBJS lists.

Rich


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-11-30 21:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-27  5:48 Storing version information in libc.so Rich Felker
2013-11-30 21:42 ` Rich Felker

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).