On Fri, 12 Nov 2010 15:13:36 +0100, Erik Cederstrand <e...@cederstrand.dk> 
wrote:
> Den 22/10/2010 kl. 12.01 skrev Ulrich Spörlein:
>> Why do you make this a requirement? Of course it's usually easier to
>> build different releases from different source directories, but I think
>> requiring the following conditions are fine:
>>
>> 1. If you build a specific svn revision,
>> 2. sitting in /usr/src with
>> 3. the default make.conf (ie., no special flags, no frobbing of OBJDIR)
>> 4. at different times
>>
>> then you get the same binaries.
>>
>> Let's start with an achievable, not-so-intrusive goal, right? :)
>
>
> Ok, here's a new attempt with SRCDIR and OBJDIR constant between the two 
> builds.
>
> This time, /boot/kernel/kernel, /boot/loader, /boot/pxeboot and
> /boot/zfsloader differ. According to strings(1), the only difference
> is the timestamp. E.g. the kernel:
>
> < @(#)FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 22:58:34 CET 2010
> < FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 22:58:34 CET 2010
> ---
>> @(#)FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 23:29:17 CET 2010
>> FreeBSD 9.0-CURRENT #0 r215143: Thu Nov 11 23:29:17 CET 2010
>
> Since the SVN rev. is recorded, I think a timestamp is redundant. Any
> ideas where I can disable the timestamps in the source?

The timestamp is not 'redundant'.  It records _when_ you compiled the
sources of the kernel, which in itself is a useful bit of information.

We could probably get away with making it an option though, e.g. in
src.conf(5) something that defaults to 'yes':

    WITH_KERNEL_TIMESTAMP='yes'

Then if it's the only remaining bit of information that changes between
two subsequent builds of precisely the same tree one can set it to 'no'
or overload it under WITH_REPEATABLE_BUILDS='yes' or similar.

FYI, have a look at "src/conf/newvers.sh" for the place where this
information is gathered at kernel-build time.

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to