Kevin Klues
I finally got around to adding a bunch of the make targets we've been
saying we wanted for years. From tools/compilers/gcc-glibc directory
the usage is now:
Usage: make <arch> [ <config> ] [ <subcmd> ]
Valid archs are: 'x86_64', 'riscv'
Valid configs are: 'cross', 'native'
Valid subcommands are: 'build', 'uninstall', check-env' 'install-headers'
If no config is specified, the 'cross' config is assumed by default.
If no subcommand is specified, the 'build' subcommand is assumed by default.
Additional pseudo targets exist for:
make clean
Cleanup the build environment
make inst-clean
Cleanup the build environment and uninstall all compilers for all archs.
For convenience, all of the valid subcommands for a cross-build of
your currently configured architecture are also exported to the top
level makefile as well (that is, the makefile at the root of the
akaros directory, rather than the one down in
tools/compilers/gcc-glibc). These targets are:
make xcc
make xcc-$(valid-subcommand)
make xcc-$(valid-pseudo-target)
make xcc-upgrade
make xcc-upgrade-from-scratch
(You should be able to tab complete on xcc- to see the full set of targets)
The two upgrade targets will rebuild the xcc, as well as rebuild (and
reinstall into kfs, if necessary) all of the bundled software that may
be affected by any changes to the cross compiler (e.g. busybox,
user-level libraries, test apps, etc.). The only difference between
the two is that xcc-upgrade-from-scratch will force a full
clean/uninstall of the xcc before attempting to rebuild it. The
xcc-upgrade target will only attempt to rebuild it from where it
previously left off.
The patches for this are on the cxx branch, starting with:
44a181: Fix typo in XCC Makefile error message output
Let me know if you have any comments/questions.
--
~Kevin
barret rhoden
...
> Let me know if you have any comments/questions.
62fc12e Make XCC uninstall robust to failures
--------------------
Can we make this less verbose?
$ make inst-clean
Removed configs, build dirs, and extracted sources
Removed ~/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/ (x86_64-cross-inst)
No INSTDIR defined to remove (x86_64-native-inst)
Removed ~/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/ (riscv-cross-inst)
which: no riscv-ucb-akaros-gcc in (/home/brho/local-usr/bin:/home/brho/local-usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2:/usr/games/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin)
which: no riscv-ucb-akaros-gcc in (/home/brho/local-usr/bin:/home/brho/local-usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2:/usr/games/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin)
No INSTDIR defined to remove (riscv-native-inst)
For instance, I don't care that I don't have a riscv-native-inst. It's
just removing the else\ block. And the which spew comes from:
ifeq ($(CONFIG),native)
ifeq ($(shell which $(ARCH)-ucb-akaros-gcc),)
when trying to do a native riscv clean.
What is this line doing?
+ [[ "$${dir}" =~ ^"$${HOME}"(/|$$) ]] && dir="~$${dir#${HOME}}";\
ab70d4e Add useful XCC targets to top level makefile
--------------------
I think this is x86 specific, but 64BIT also applies to riscv.
+ifeq ($(CONFIG_64BIT),y)
+ xcc_target := $(xcc_target)_64
+endif
What's going on with the environment in this commit?
+# Save the ability to export the parent's original environment for future use
+export_parent_env := $(shell export | sed 's/$$/;/')
+
+# Save the ability to clear the current environment for future use
+clear_current_env := for c in $$(env | cut -d '=' -f 1); do unset $$c; done;
+
I had an issue with make xcc, maybe related to env issues, during
stage 1 glibc:
checking for x86_64-ucb-akaros-nm... x86_64-ucb-akaros-nm
checking LD_LIBRARY_PATH variable... contains current directory
configure: error:
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.
Makefile:488: recipe for target '.x86_64-ucb-akaros-glibc-stage1-configure' failed
make[2]: *** [.x86_64-ucb-akaros-glibc-stage1-configure] Error 1
Makefile:209: recipe for target 'build-real' failed
make[1]: *** [build-real] Error 2
Makefile:69: recipe for target 'make-real' failed
make: *** [make-real] Error 2
Makefile:660: recipe for target 'xcc-build' failed
make: *** [xcc-build] Error 2
b04128 Add 'xcc-upgrade' and 'xcc-upgrade-from-scratch'
-------------------------
for the upgrade:
+xcc-upgrade:
+ @$(clear_current_env)\
+ $(export_parent_env)\
+ $(MAKE) xcc;\
+ $(MAKE) -C tools/apps/busybox
+ $(MAKE) akaros-kernel install-libs testclean tests fill-kfs
are these building in the right order? akaros-kernel needs to be done
after fill-kfs. likewise, fill-kfs needs to be done after tests
(though it will trigger a tests build on its own). busybox relies on
install-libs (though xcc does that internally). tests will trigger an
install-libs too.
also, the trailing \ seems like something we can screw up in the
future. the first 4 lines are all one command, with the env stuff, but
the last is a regular make.
maybe it'd be easier with both the \ and with the ordering to have
specific make targets with dependencies? like, xcc-upgrade depends on
xcc and some 'xcc-apps' variable (consisting of busybox for now), and
the xcc-apps target depends on xcc and does the MAKE -C
tools/apps/APPDIR or something.
though for the kernel, akaros-kernel doesn't actually depend on
fill-kfs, it's just that the user wants to do that in this order in
this case, so i'd just break that into two MAKEs.
similarly with upgrade-from-scratch, it could just depend on inst-clean
or something. that's less big of a deal, since it looks like it'll
work.
barret
Dan Cross
Kevin Klues
> On 2015-07-14 at 23:42 Kevin Klues wrote:
> ...
>> Let me know if you have any comments/questions.
>
>
> 62fc12e Make XCC uninstall robust to failures
> --------------------
>
> Can we make this less verbose?
Actually, the point of this commit was to do make it less verbose....
I don't see that long output like you do. I was attempting to make
each target print exactly one line (Removed ... if successful, No
INSTDIR ... if failure. My output looks like the following (I don't
have any riscv stuff installed either):
Removed configs, build dirs, and extracted sources
Removed ~/install/x86_64-ucb-akaros-gcc/ (x86_64-cross-inst)
Removed ~/install/x86_64-ucb-akaros-gcc-native/ (x86_64-native-inst)
Removed ~/install/riscv-ucb-akaros-gcc/ (riscv-cross-inst)
No INSTDIR defined to remove (riscv-native-inst)
It looks like the difference is that my 'which' command returns
nothing if that path doesn't exist. It looks like yours actually
returns an error.
>
> $ make inst-clean
> Removed configs, build dirs, and extracted sources
> Removed ~/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/ (x86_64-cross-inst)
> No INSTDIR defined to remove (x86_64-native-inst)
> Removed ~/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/ (riscv-cross-inst)
> which: no riscv-ucb-akaros-gcc in (/home/brho/local-usr/bin:/home/brho/local-usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2:/usr/games/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin)
> which: no riscv-ucb-akaros-gcc in (/home/brho/local-usr/bin:/home/brho/local-usr/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2:/usr/games/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin:/usr/local/cuda/bin:/home/brho/classes/ros/ros-gcc-glibc/install-x86_64-ros-gcc/bin:/home/brho/classes/ros/ros-gcc-glibc/install-riscv-ros-gcc/bin:/home/brho/classes/ros/go/bin)
> No INSTDIR defined to remove (riscv-native-inst)
>
> For instance, I don't care that I don't have a riscv-native-inst. It's
> just removing the else\ block. And the which spew comes from:
I'm fine with removing the else line. I will pipe the output of the
'which' command to /dev/null like we do with our other similar
commands.
>
> ifeq ($(CONFIG),native)
> ifeq ($(shell which $(ARCH)-ucb-akaros-gcc),)
>
> when trying to do a native riscv clean.
>
> What is this line doing?
>
> + [[ "$${dir}" =~ ^"$${HOME}"(/|$$) ]] && dir="~$${dir#${HOME}}";\
This line just translates the absolute path for ${dir} to print as
~/path/to/dir if it happens to be in your home directory (though it
actually assumes that you have it somewhere in your home directory
because it unconditionally adds the ~ even if it's not. We don't need
to keep it. I added it in the spirit of keeping things more readable.
>
>
>
>
> ab70d4e Add useful XCC targets to top level makefile
> --------------------
> I think this is x86 specific, but 64BIT also applies to riscv.
>
> +ifeq ($(CONFIG_64BIT),y)
> + xcc_target := $(xcc_target)_64
> +endif
Yeah, I wasn't sure what to do here. I was thinking we would just make
the riscv 64 bit target be called riscv_64 once we cross that bridge,
then this would just work. If you have any better suggestions, I'm
all ears.
>
> What's going on with the environment in this commit?
>
> +# Save the ability to export the parent's original environment for future use
> +export_parent_env := $(shell export | sed 's/$$/;/')
> +
> +# Save the ability to clear the current environment for future use
> +clear_current_env := for c in $$(env | cut -d '=' -f 1); do unset $$c; done;
> +
All of the exports you do in the top level Makefile, mess with the
settings of the xcc Makefile (and busybox's Makefile) when we do a
recursive make. These lines make it so that later on I can just clear
out the current environment and restore the environment of the parent
just before making my recursive make calls. It was just easier than
manually going through and 'unexporting' everything that the Makefile
exported. It also keeps us from having to keep these exports in sync
with unexporting them somewhere else. At the end of the day, it boils
down to the fact that our xcc make wants the environment set up in our
shell, not the one set up in the top level makefile.
>
> I had an issue with make xcc, maybe related to env issues, during
> stage 1 glibc:
>
> checking for x86_64-ucb-akaros-nm... x86_64-ucb-akaros-nm
> checking LD_LIBRARY_PATH variable... contains current directory
> configure: error:
> *** LD_LIBRARY_PATH shouldn't contain the current directory when
> *** building glibc. Please change the environment variable
> *** and run configure again.
> Makefile:488: recipe for target '.x86_64-ucb-akaros-glibc-stage1-configure' failed
> make[2]: *** [.x86_64-ucb-akaros-glibc-stage1-configure] Error 1
> Makefile:209: recipe for target 'build-real' failed
> make[1]: *** [build-real] Error 2
> Makefile:69: recipe for target 'make-real' failed
> make: *** [make-real] Error 2
> Makefile:660: recipe for target 'xcc-build' failed
> make: *** [xcc-build] Error 2
That has always been an error if you have LD_LIBRARY_PATH setup. I
run into this periodically myself (and have for years). That is
actually one case where we should probably manually unset that
variable at the top of the xcc makefile itself.
>
>
> b04128 Add 'xcc-upgrade' and 'xcc-upgrade-from-scratch'
> -------------------------
> for the upgrade:
> +xcc-upgrade:
> + @$(clear_current_env)\
> + $(export_parent_env)\
> + $(MAKE) xcc;\
> + $(MAKE) -C tools/apps/busybox
> + $(MAKE) akaros-kernel install-libs testclean tests fill-kfs
>
> are these building in the right order? akaros-kernel needs to be done
> after fill-kfs. likewise, fill-kfs needs to be done after tests
> (though it will trigger a tests build on its own). busybox relies on
> install-libs (though xcc does that internally). tests will trigger an
> install-libs too.
We can change this order. I think I actually had them in the order you
mention, but rearranged them to put busybox in line with xcc since
they both needed the clear_current_env/export_parent_env stuff.
>
> also, the trailing \ seems like something we can screw up in the
> future. the first 4 lines are all one command, with the env stuff, but
> the last is a regular make.
There was no real good way around this (unless we split up the
targets). Maybe that's what we should actually just do.
>
> maybe it'd be easier with both the \ and with the ordering to have
> specific make targets with dependencies? like, xcc-upgrade depends on
> xcc and some 'xcc-apps' variable (consisting of busybox for now), and
> the xcc-apps target depends on xcc and does the MAKE -C
> tools/apps/APPDIR or something.
>
> though for the kernel, akaros-kernel doesn't actually depend on
> fill-kfs, it's just that the user wants to do that in this order in
> this case, so i'd just break that into two MAKEs.
>
> similarly with upgrade-from-scratch, it could just depend on inst-clean
> or something. that's less big of a deal, since it looks like it'll
> work.
Yeah, this would probably do it. I'll come up with something I think
is reasonable and update the branch. I'll let you know when I've
finished.
--
~Kevin
Kevin Klues
this sort of cleanup. We already have 'make mrproper' (following the
linux convention) for true cleanup of everything.
--
~Kevin
barret rhoden
> I'm fine with removing the else line. I will pipe the output of the
> 'which' command to /dev/null like we do with our other similar
> commands.
Sounds good.
> > ifeq ($(CONFIG),native)
> > ifeq ($(shell which $(ARCH)-ucb-akaros-gcc),)
> >
> > when trying to do a native riscv clean.
> >
> > What is this line doing?
> >
> > + [[ "$${dir}" =~ ^"$${HOME}"(/|$$) ]] &&
> > dir="~$${dir#${HOME}}";\
>
> This line just translates the absolute path for ${dir} to print as
> ~/path/to/dir if it happens to be in your home directory (though it
> actually assumes that you have it somewhere in your home directory
> because it unconditionally adds the ~ even if it's not. We don't need
> to keep it. I added it in the spirit of keeping things more readable.
I was just a bit surprised that we had anything that cared about the
HOME directory. I happen to have my dir under ~, but there's no need
for it.
> > ab70d4e Add useful XCC targets to top level makefile
> > --------------------
> > I think this is x86 specific, but 64BIT also applies to riscv.
> >
> > +ifeq ($(CONFIG_64BIT),y)
> > + xcc_target := $(xcc_target)_64
> > +endif
>
> Yeah, I wasn't sure what to do here. I was thinking we would just make
> the riscv 64 bit target be called riscv_64 once we cross that bridge,
> then this would just work. If you have any better suggestions, I'm
> all ears.
I think the riscv toolchain works for both 32 and 64 bit, so we didn't
need to make a distinction. I was thinking of making it just "if x86,
then x86_64". we're probably never going to go back to x86 32 anyways.
> All of the exports you do in the top level Makefile, mess with the
> settings of the xcc Makefile (and busybox's Makefile) when we do a
> recursive make. These lines make it so that later on I can just clear
> out the current environment and restore the environment of the parent
> just before making my recursive make calls. It was just easier than
> manually going through and 'unexporting' everything that the Makefile
> exported. It also keeps us from having to keep these exports in sync
> with unexporting them somewhere else. At the end of the day, it boils
> down to the fact that our xcc make wants the environment set up in our
> shell, not the one set up in the top level makefile.
so if i understand correctly, export_parent_env saves the environment
of the initial makefile call (with some mangling of "$$"?), before the
makefile adds anything to the export. then when we want to do a
submake-without-export, we blow away everything with the command that
is saved in clear_current_env.
that seems fine. another thing we could do would be to make it so that
our submakes (xcc, busybox) can handle the exports, which might even
make their jobs easier. maybe it's not worth the hassle.
> > I had an issue with make xcc, maybe related to env issues, during
> > stage 1 glibc:
> >
> > checking for x86_64-ucb-akaros-nm... x86_64-ucb-akaros-nm
> > checking LD_LIBRARY_PATH variable... contains current directory
> > configure: error:
> > *** LD_LIBRARY_PATH shouldn't contain the current directory when
> > *** building glibc. Please change the environment variable
> > *** and run configure again.
> > Makefile:488: recipe for target
> > '.x86_64-ucb-akaros-glibc-stage1-configure' failed make[2]: ***
> > [.x86_64-ucb-akaros-glibc-stage1-configure] Error 1 Makefile:209:
> > recipe for target 'build-real' failed make[1]: *** [build-real]
> > Error 2 Makefile:69: recipe for target 'make-real' failed
> > make: *** [make-real] Error 2
> > Makefile:660: recipe for target 'xcc-build' failed
> > make: *** [xcc-build] Error 2
>
> That has always been an error if you have LD_LIBRARY_PATH setup. I
> run into this periodically myself (and have for years). That is
> actually one case where we should probably manually unset that
> variable at the top of the xcc makefile itself.
I bisected this to
20192c8b Complete rewrite of Makefile
I happen to have tried the toolchain build on a computer that I hadn't
used in a couple weeks that has LD_LIBRARY_PATH set.
barret
Kevin Klues
> On 2015-07-15 at 7:40 Kevin Klues wrote:
>> I'm fine with removing the else line. I will pipe the output of the
>> 'which' command to /dev/null like we do with our other similar
>> commands.
>
> Sounds good.
>
>> > ifeq ($(CONFIG),native)
>> > ifeq ($(shell which $(ARCH)-ucb-akaros-gcc),)
>> >
>> > when trying to do a native riscv clean.
>> >
>> > What is this line doing?
>> >
>> > + [[ "$${dir}" =~ ^"$${HOME}"(/|$$) ]] &&
>> > dir="~$${dir#${HOME}}";\
I've removed it. The main reason I did it is because my home
directory is at a really long path, so it was wrapping strangely in my
terminal and figured I might as well translate it to ~ to make it look
nicer. Not a big deal though. It's gone now.
>>
>> This line just translates the absolute path for ${dir} to print as
>> ~/path/to/dir if it happens to be in your home directory (though it
>> actually assumes that you have it somewhere in your home directory
>> because it unconditionally adds the ~ even if it's not. We don't need
>> to keep it. I added it in the spirit of keeping things more readable.
>
> I was just a bit surprised that we had anything that cared about the
> HOME directory. I happen to have my dir under ~, but there's no need
> for it.
>
>> > ab70d4e Add useful XCC targets to top level makefile
>> > --------------------
>> > I think this is x86 specific, but 64BIT also applies to riscv.
>> >
>> > +ifeq ($(CONFIG_64BIT),y)
>> > + xcc_target := $(xcc_target)_64
>> > +endif
>>
>> Yeah, I wasn't sure what to do here. I was thinking we would just make
>> the riscv 64 bit target be called riscv_64 once we cross that bridge,
>> then this would just work. If you have any better suggestions, I'm
>> all ears.
>
> I think the riscv toolchain works for both 32 and 64 bit, so we didn't
> need to make a distinction. I was thinking of making it just "if x86,
> then x86_64". we're probably never going to go back to x86 32 anyways.
I'm fine with that. We can cross this bridge again later if it ever
comes up again.
>
>> All of the exports you do in the top level Makefile, mess with the
>> settings of the xcc Makefile (and busybox's Makefile) when we do a
>> recursive make. These lines make it so that later on I can just clear
>> out the current environment and restore the environment of the parent
>> just before making my recursive make calls. It was just easier than
>> manually going through and 'unexporting' everything that the Makefile
>> exported. It also keeps us from having to keep these exports in sync
>> with unexporting them somewhere else. At the end of the day, it boils
>> down to the fact that our xcc make wants the environment set up in our
>> shell, not the one set up in the top level makefile.
>
> so if i understand correctly, export_parent_env saves the environment
> of the initial makefile call (with some mangling of "$$"?), before the
> makefile adds anything to the export. then when we want to do a
> submake-without-export, we blow away everything with the command that
> is saved in clear_current_env.
We can't really do it at a lower level because (for example), we set
CC and that would completely screw the xcc build (unless we unset it
down there). Though maybe sometimes we would want to set CC
legitimately from our shell when invoking the xcc make directly. If we
unset it explicitly, this would't be possible.
--
~Kevin
Dan Cross
Which one would you call distclean? I didn't add anything that does
this sort of cleanup. We already have 'make mrproper' (following the
linux convention) for true cleanup of everything.
Kevin Klues
44a181: Fix typo in XCC Makefile error message output
> What is this line doing?
>
> + [[ "$${dir}" =~ ^"$${HOME}"(/|$$) ]] && dir="~$${dir#${HOME}}";\
> ab70d4e Add useful XCC targets to top level makefile
> --------------------
> I think this is x86 specific, but 64BIT also applies to riscv.
>
> +ifeq ($(CONFIG_64BIT),y)
> + xcc_target := $(xcc_target)_64
> +endif
Kevin
--
~Kevin
Kevin Klues
having to do both a 'make uninstall' and a 'make distclean' separately
for most projects. My understanding was that distclean was to remove
all generated files from 'configure' and regular clean was to remove
all files generated by 'make'. Since we don't have a 'configure' I
never made a 'distclean' target.
--
~Kevin
Dan Cross
Barret Rhoden
> OK, I've patched things up. First commit unchanged:
> 44a181: Fix typo in XCC Makefile error message output
f80c3fd36438 ("Add useful XCC targets to top level makefile")
thanks for the clarification in the message, and this is nice:
+define make_as_parent
+ @$(clear_current_env)\
+ $(export_parent_env)\
+ $(MAKE) --no-print-directory $(1)
+endef
though it sucks that it can't be used down below:
+$(xcc_clean_goals):
+ @$(clear_current_env)\
+ $(export_parent_env)\
+ target="$(patsubst xcc-%,%,$(@))";\
+ $(MAKE) --no-print-directory -C $(xcc_build_dir) $${target}
would something like this work?
+$(xcc_clean_goals):
+ @target="$(patsubst xcc-%,%,$(@))";\
+ $(call make_as_parent, -C $(xcc_build_dir) $${target}}
with the assumption that anyone using make_as_parent deals with the @
on their own (or have clear_current_env and export_parent_env not make
as much noise (if any)).
based on a minor testing, you can pass a bunch of args with $(call),
and they all count as arg1 so long as they aren't comma-separated.
e9e0f4e0f5a3 ("Add targets to install/clean bundled apps")
this could use the new make_as_parent too, if the stuff above works.
if not, oh well.
e2ca5a8430b5 ("Add 'xcc-upgrade' and 'xcc-upgrade-from-scratch'")
+xcc-upgrade: xcc
+ $(MAKE) userclean
+ $(MAKE) install-libs
+ $(MAKE) testclean utestclean
+ $(MAKE) tests utest
+ $(call make_as_parent, apps-clean)
+ $(call make_as_parent, apps-install)
+ $(MAKE) akaros-kernel
+ $(MAKE) fill-kfs
the last two are backwards.
barret
Kevin Klues
That's a good idea. I will make the change right now.
>
>
> e9e0f4e0f5a3 ("Add targets to install/clean bundled apps")
>
> this could use the new make_as_parent too, if the stuff above works.
> if not, oh well.
>
>
> e2ca5a8430b5 ("Add 'xcc-upgrade' and 'xcc-upgrade-from-scratch'")
>
> +xcc-upgrade: xcc
> + $(MAKE) userclean
> + $(MAKE) install-libs
> + $(MAKE) testclean utestclean
> + $(MAKE) tests utest
> + $(call make_as_parent, apps-clean)
> + $(call make_as_parent, apps-install)
> + $(MAKE) akaros-kernel
> + $(MAKE) fill-kfs
>
> the last two are backwards.
On it.
--
~Kevin
Kevin Klues
--
~Kevin