I saw other projects have a "compile" or "link" wrapper scripts, which do that. cmake (n.1 truly multi-platform make system IMO) is one, for example.
On Sat, Nov 21, 2015 at 8:31 AM, Kevin Klues <[email protected]> wrote: > 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]> 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]. >>> To post to this group, send email to [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]. >> To post to this group, send email to [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. > -- 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.
