Overachiever! ☺ Why would you not store the sources? 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 pass and libs?
Moreover, I find it nice that there is a common make machinery, which emits a consistent output while building. 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 The a master make machinery can read that, and do the proper building. BTW, Busybox is not a very nice example, as even if there is nothing new to build, it does a bunch of things. On Fri, Nov 20, 2015 at 5:51 PM, Kevin Klues <[email protected]> wrote: > I'd personally rather see an external framework that can be told how > to build libs and apps on a per lib/app basis and install them into > the akaros kfs via make magic. Something like: > > akaros-pkg-builder/ > ├── pkg/ > ├── sysroot/ > ├── .gitignore > ├── .config > └── Makefile > > Where we use ncurses to select packages we know how to build, and we > have per-package Makefiles in the 'pkg' directory which the top level > Makefile can invoke to build and install a specific package. Packages > would then be installed into the 'sysroot' directory and recursively > copied into $AKAROS_ROOT/kern/kfs once all selected packages were > built. We could also remove them from kfs via the reverse operation. > > I wouldn't store the source for any of these packages in this repo > directly, but I would store patches to upstream libs/apps in here > (kind of like we do for busybox in the akaros repo). So per-package > Makefiles would know how to fetch the appropriate source from wherever > it is hosted, apply any relevant patches, build the source, and > install it into 'sysroot'. > > As a concrete example, if busybox were moved out into this framework: > > akaros-pkg-builder/ > ├── pkg > │ └── busybox > │ ├── akaros-patches > │ │ └── 1.17.3 > │ │ ├── 0001-busybox-perror-with-errstr.patch > │ │ ├── 0002-busybox-create-errstr.patch > │ │ ├── 0003-busybox-rm-rewinddir.patch > │ │ ├── 0004-busybox-shell-resource.patch > │ │ ├── 0005-bb-echo-perror.patch > │ │ ├── 0006-busybox-major-minor-makedev.patch > │ │ └── 0007-echo-buffering.patch > │ ├── busybox-1.17.3-akaros > │ │ ├── ... > │ │ ├── ... > │ │ ├── ... > │ ├── upstream-patches > │ └── 1.17.3 > │ ├── busybox-1.17.3-dnsd.patch > │ ├── busybox-1.17.3-iproute.patch > │ ├── busybox-1.17.3-ls.patch > │ ├── busybox-1.17.3-sort.patch > │ └── busybox-1.17.3-unicode.patch > │ ├── .gitignore > │ ├── busybox-1.17.3.tar.bz2 > │ ├── defconfig-1.17.3 > │ └── Makefile > ├── sysroot > ├── .config > ├── .gitignore > └── Makefile > > The only requirement being that any folders under pkg have a Makefile > in them. After that, they can contain their own .gitignore to decide > what should be ignored and what should be kept as part of the repo. > For busybox, the Makefile, all of the patches, and the defconfig would > become part of the repo, while everything else would be ignored. > > By convention, the per-pkg Makefile will need to have 'make' 'make > install', and 'make uninstall' targets. Under the hood it will invoke > the actual Makefile of the package (or whatever build system it uses) > to build the package before installing/uninstalling it into 'sysroot'. > Invoking 'make', 'make install', or 'make uninstall' on the top level > Makefile will simply iterate through the directories in pkg that have > been selected in the ncurses config and forward those commands onto > them. > > This is actually similar to what we do currently within the Akaros > tree using the top level akaros Makefile. I'm just proposing to move > it to an external repo and start expanding it. > > Thoughts? > > On Fri, Nov 20, 2015 at 4:59 PM, 'Davide Libenzi' via Akaros > <[email protected]> wrote: > > Currently we use that for user/ builds, but that assumes a static library > > being built. > > I introduced two more targets in master. > > One is 'snc', which is the Akaros simple netcat (should build only for > > Akaros), and the other one is krpfo2perf, which is the kprof to Linux > perf > > file format converted (which should build for bot Linux and Akaros). > > Currently these two targets have their own Makefiles, called by make-C, > from > > the master Makefile. > > Ideally we could have a Makefrag-libs and Makefrag-apps in the root > > directory, one for libraries and one for apps (or one handling both). > > On the root directory, so that it could be used from tools/ as well. > > It leaves open how to have a target build for both Linux and Akaros... > > > > -- > > 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.
