Moving from .uu.o -> .o in the kernel
Michael Gmelin
freebsd at grem.de
Thu Apr 8 13:51:14 UTC 2021
On Thu, 08 Apr 2021 13:15:38 +0000
"Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net> wrote:
> On 8 Apr 2021, at 5:26, Warner Losh wrote:
>
> Hi,
>
> > In preparations for bringing a new vendor driver in, I realized
> > that one of
> > the promises of svn was that one could store .o files in the repo.
> > We never
> > did that, preferring to stick with the old CVS trick of storing the
> > .o files as .o.uu files and converting them as part of the build
> > process.
> ..
> >
> > My proposal is to simplify. I propose that we remove the .uu files
> > and just
> > commit the .o files and adjust the build to simplify it. It turns
> > out that
> > our config(8) knows that when there's a .o in the kernel files*
> > file, just
> > to copy that .o file over when the driver is in the tree.
>
>
> and we’ve done similar things for, e.g., firmware files storing the
> binary
> rather than the uuencoded versions in the tree. I am all for the
> simplification!
>
>
> I am a bit concerned with .o files in random places in the source
> tree though as
> they may show up and various tooling people have might clean them up.
> I’d suggested to keep it in mind and go ahead and do a few and see if
> it becomes
> a practical issue rather than just a theoretical one before taking
> any actions ..
Personally, I would prefer to use a custom extension (like .obj, .srco,
.bin, ...) as finger memory will produce things like
`find . -name \*.o -delete' (and tooling, like Bjoern said, might
bite us as well).
If you still decide to use the .o extension, I would make sure to
- keep *.o in the top-level .gitignore file to avoid checking in
objects by accident.
- explicitly make exemptions where needed.
So, e.g., .gitignore would contain *.o, while
sys/contrib/dev/mwl/.gitignore would contain
!mwlboot.fw.o
!mw88W8363.fw.o
to explicitly just exclude the files in question from being ignored.
Best,
Michael
>
>
> /bz
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to
> "freebsd-arch-unsubscribe at freebsd.org"
--
Michael Gmelin
More information about the freebsd-arch
mailing list