for emacs/make aware people

[ron minnich]

our makefiles are not really suitable for emacs users. I think it's in part because we're using recursive make, which is 

http://aegis.sourceforge.net/auug97.pdf

considered harmful.

The problem with our make style is emacs can never find what file had what error. This is very trying.

Anyway, one project at some point is to rehash our make setup, because another thing we lack is the ability to do this:

cd tests

make

which I'd like to have. I can't believe I'm the only one.

We dumped recursive make about 6 years back on coreboot and were glad we did. We dropped make entirely on harvey, because compilers are fast now and make magic is painful to get right -- few projects get it entirely right, which is why so many of us type 'make clean' anytime anything goes wrong. We don't miss make. Much. That said, for the Rest of The World, we obviously will continue to make make easy to use.

Last problem: in a kernel project having user mode stuff building inside the kernel tree is going to stop scaling. So yet another project :-) is to get our user mode stuff out of the kernel tree entirely. It's easier to find out what kind of trouble you're going to cause others.

ron

[Barret Rhoden]

On 2015-08-03 at 15:33 ron minnich <rmin...@gmail.com> wrote:
> our makefiles are not really suitable for emacs users. I think it's
> in part because we're using recursive make, which is
> http://aegis.sourceforge.net/auug97.pdf
> considered harmful.

i happen to like recursive make. it's a tool and it works. i also use
gotos, despite those being 'considered harmful'.

on that note, “Considered Harmful” Essays Considered Harmful
http://meyerweb.com/eric/comment/chech.html

=)

> The problem with our make style is emacs can never find what file had
> what error. This is very trying.

if we can make a change that helps with that without disrupting our
existing setup too much, then go for it.

> Anyway, one project at some point is to rehash our make setup, because
> another thing we lack is the ability to do this:
> cd tests
> make
>
> which I'd like to have. I can't believe I'm the only one.

i pretty much always work from the top-level directory. the exceptions
are when i'm working in the toolchain or something.

> Last problem: in a kernel project having user mode stuff building
> inside the kernel tree is going to stop scaling. So yet another
> project :-) is to get our user mode stuff out of the kernel tree
> entirely. It's easier to find out what kind of trouble you're going
> to cause others.

we've kept user/ and kern/ in the same tree since the kernel interface
is not stable and we regularly update both of them at the same time. i
don't want to mess around with multiple git repos, especially since our
general M.O. is to just rebuild everything. we're just more like BSD
(and Plan 9) than Linux in that regard.

honestly, if you don't keep up with the commit messages, then anytime
you pull from master or something fails, just run:

$ make xcc-upgrade-from-scratch

as kevin mentioned last week. it takes a long time and is probably
overkill, which is why i go through the effort of telling people what to
do in the commit messages. for instance, any commit that could require
a toolchain rebuild or kernel headers re-installation should be marked
(XCC) in the commit message. in the text of the commit i'll usually
say what aspect of the toolchain needs rebuilt.

kevin and i talked about adding some logic that attempts to notice when
your toolchain is out of date and automatically rebuild it. so long as
it's done in a way that doesn't interfere with people who develop the
toolchain, then that could be a help.

barret

[Kevin Klues]

Just to add. I think we tend to revisit the topic of "get rid of
recursive make" and "move user out of the kernel repo" at least once a
year or so, and always end up reaching the same conclusion: there's no
good reason to do it other than other people consider it bad practice,
and for the most part it would actually make our lives harder rather
than easier.

For example, if we moved the user stuff out of the kernel repo there
would now be an extra dependency to track to make sure that the SHA1
of the user repo was compatible with the SHA1 of the kernel repo so
that they will work together properly. Likewise, with the toolchain,
the kernel, and the user directory together. I already run into this
problem with Go all the time, but I tend to track the kernel repo
commits pretty closely so I know when I need to update stuff.

Regarding recursive make. Part of the reason it may be harder to
figure out which makefile you are currently in, is that we pass
"--no-print-directory" to make by default. With this option it
doesn't show you when you call a makefile in another directory, so it
may look as though you are still executing the makefile at the top
level. We turn this on to make all of our output less verbose though.
We could consider (optionally) turning it back on to help debug stuff.

I think the bottom line is that with the amount of churn we still have
with our kernel/user/and toolchain interfaces, pulling them out into
separate repos would actually be harder to maintain right now than
keeping them together. We will obviously need to separate them at
some point as things become more stable. Probably at the same time we
finally settle on an Akaros version 1.0 with a supported set of
interfaces, etc. Until then it only makes things harder though.

In my opinion, the right tihing right now is to make it clear that all
make commands should be executed ONLY from the top level directory,
and make it clearer, exactly what those make commands are.

--
~Kevin

[Kevin Klues]

By the way, what exactly are the problems with emacs? Maybe we can
address that a different way?

--
~Kevin

[ron minnich]

It can never find the file in which build errors occurred. Maybe the no-print-directory is the cause.

ron

[Kevin Klues]

Resolved by:

https://github.com/brho/akaros/commit/0a072c11e67a3340270844f1a1951d9177fe576c