Yeah, that seems like the way to go. Parsing wouldn't be that hard either, I imagine.
On Saturday, November 21, 2015, 'Davide Libenzi' via Akaros < [email protected]> wrote: > Oh, I agree. If the target is mass import, it is not practical to rewrite > all the makefiles. > At that point, if makefiles are reasonably following the standard, they > will read env for CC, LD, CFLAGS, CXXFLAGS, PREFIX, ..., so we can feed > them the proper values. > All autoconf/automake based ones (a lot of OSS stuff), are following that > standard. > We could feed them, instead of Akaros gcc binaries directly, a wrapper > script which parses the cmdline and does the clean output. > > > On Fri, Nov 20, 2015 at 7:54 PM, Kevin Klues <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> > Overachiever! >> > Why would you not store the sources? >> >> Because I'm picturing some of these packages being actively developed >> elsewhere (e.g. dorpbear-akaros). >> >> > You are describing what is that distributions do (source packages >> contain the tar.gz of the original source, plus distro patches), but they >> do store the tar.gz. >> > Also, what about in-tree apps and libs? >> >> We could keep some in there with the nice one-line compiling, but it's >> not necessarily appropriate for everything. >> >> > Moreover, I find it nice that there is a common make machinery, which >> emits a consistent output while building. >> >> I agree. I am the one who wrote it that way :) >> >> > If every package implements its own make system, this is lost. >> > IMHO the build configuration for packages should be declaring, per >> target: >> > >> > 1) Target type (exe, lib, so, ...) >> > 2) The files to build (with possible "glob" spec which resorts to the >> actual *.c,*.S,...) >> > 3) CFLAGS options. Global, with possible per-file override. >> > 4) LDFLAGS >> > 5) What to install and where >> >> I agree, except if we want to start porting over a wide variety of >> packages, it's intractable to port all of their makefiles to follow >> this pattern. Standardizing on a way to get them installed in kfs (or >> even through a 9p mount point) is important though. >> >> > BTW, Busybox is not a very nice example, as even if there is nothing >> new to build, it does a bunch of things. >> >> Sure, but it will always do that unless we change something in the >> busybox makefile itself (which isn't unreasonable). >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Akaros" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <javascript:_e(%7B%7D,'cvml','akaros%[email protected]');>. >> To post to this group, send email to [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <javascript:_e(%7B%7D,'cvml','akaros%[email protected]');>. > To post to this group, send email to [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>. > For more options, visit https://groups.google.com/d/optout. > -- ~Kevin -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
