OpenIndiana / Oi Userland
Unified build system for OpenIndiana distribution components
Stars: ✭ 129
Programming Languages
c
50402 projects - #5 most used programming language
Labels
Projects that are alternatives of or similar to Oi Userland
Boneos
💥 BoneOS Kernel and Operating System Source Tree
Stars: ✭ 96 (-25.58%)
Mutual labels: operating-system
Papers Notebook
📄 🇨🇳 📃 论文阅读笔记(分布式系统、虚拟化、机器学习)Papers Notebook (Distributed System, Virtualization, Machine Learning), created by @gaocegege
Stars: ✭ 1,678 (+1200.78%)
Mutual labels: operating-system
Raspberry Pi Os
Learning operating system development using Linux kernel and Raspberry Pi
Stars: ✭ 11,000 (+8427.13%)
Mutual labels: operating-system
Rcore Tutorial Book V3
v3.5 https://rcore-os.github.io/rCore-Tutorial-Book-v3/
Stars: ✭ 102 (-20.93%)
Mutual labels: operating-system
Serenity
SerenityOS is a love letter to '90s user interfaces with a custom Unix-like core. It flatters with sincerity by stealing beautiful ideas from various other systems.
Stars: ✭ 16,842 (+12955.81%)
Mutual labels: operating-system
Snakeware
A free Linux distro with a Python-based userspace
Stars: ✭ 1,514 (+1073.64%)
Mutual labels: operating-system
Computer Science Resources
A list of resources in different fields of Computer Science (multiple languages)
Stars: ✭ 1,316 (+920.16%)
Mutual labels: operating-system
Operating Systems Three Easy Pieces
operating systems three easy pieces by Rezmi
Stars: ✭ 128 (-0.78%)
Mutual labels: operating-system
Jingos
JingOS - The World’s First Linux-based OS design for Tablets
Stars: ✭ 101 (-21.71%)
Mutual labels: operating-system
Packer Bare Metal
Building bare metal OS images with Packer, VirtualBox and qemu-img
Stars: ✭ 115 (-10.85%)
Mutual labels: operating-system
Balena Os
The central place for all things BalenaOS related.
Stars: ✭ 104 (-19.38%)
Mutual labels: operating-system
Aura Operating System
AuraOS, the Franco-English Operating System developed in C# using Cosmos!
Stars: ✭ 111 (-13.95%)
Mutual labels: operating-system
Setup
My own front end web development set up, covering everything from operating system to analytics.
Stars: ✭ 93 (-27.91%)
Mutual labels: operating-system
Reading
A list of computer-science readings I recommend
Stars: ✭ 1,919 (+1387.6%)
Mutual labels: operating-system
Getting started with the Userland Consolidation
Getting Started
This README provides a very brief overview of the gate, how to retrieve
a copy, and how to build it. Detailed documentation about the Userland
gate can be found in the 'doc' directory. Questions or comments about
the gate can be addressed to [email protected]
Overview
The Userland consolidation maintains a Git repository at
https://github.com/OpenIndiana/oi-userland
This gate contains build recipies, patches, IPS manifests, etc. necessary
to download, prep, build, test, package and publish open source software.
The build infrastructure is similiar to that of the SFW consolidation in
that it makes use of herarchical Makefiles which provide dependency and
recipe information for building the components. In order to build the
contents of the Userland gate, you need to clone it. Since you are
reading this, you probably already have.
Getting the Bits
As mentioned, the gate is stored in a Git repository. In order to
build or develop in the gate, you will need to clone it. You can do so
with the following command
$ git clone https://github.com/OpenIndiana/oi-userland.git /scratch/clone
This will create a replica of the various pieces that are checked into the
source code management system, but it does not retrieve the community
source archives associated with the gate content. To download the
community source associated with your cloned workspace, you will need to
execute the following:
$ cd /scratch/clone/components
$ gmake download
This will use GNU make and the downloading tool in the gate to walk through
all of the component directories downloading and validating the community
source archives from the gate machine or their canonical source repository.
There are two variation to this that you may find interesting. First, you
can cause gmake(1) to perform it's work in parallel by adding '-j (jobs)'
to the command line. Second, if you are only interested in working on a
particular component, you can change directories to that component's
directory and use 'gmake download' from that to only get it's source
archive.
Also, when you start to work with a new archive file - update the source
version in an existing recipe component, or start a new one from scratch -
you can use 'gmake fetch' to download the archive(s) defined in the new
recipe, calculate the checksums and *NOT* remove the archive because its
actual checksum does not match the value recorded in the recipe Makefile
(if any) so the download is deemed corrupted while you know it is not.
There is also a side-effect: by framework recipe, a file in the download
location only depends on the component recipe Makefile. So once an archive
is "fetched" (downloaded and not removed), it will not be re-verified -
the downloading script is just not called. This is a moderate problem,
since the "fetch" ability is a helper for recipe-makers doing initial
archive downloads in a certain situation, to save some traffic and time
on their workstations. You can still remove files fetched by a recipe
using 'gmake clobber'.
Building the Bits
You can build individual components or the contents of the entire gate.
Integration with ccache to speed up re-builds
If you happen to build the same sources several times (e.g. iterating
attempts to produce a working recipe, or maintaining an automated build
server), you can benefit from 'ccache' integration in 'oi-userland'.
Note that this feature is currently experimental and off by default.
The 'ccache' component is available as part of the project repository.
Once you have the resulting package installed, you can pass the 'make'
argument or environment variable 'ENABLE_CCACHE=true' to wrap the GNU
compiler invocations with the caching program - so that the same inputs
would re-produce same outputs quickly.
You can pre-set this variable in your user account '~/.profile' like this:
### To speed up OI-userland re-builds
ENABLE_CCACHE=true
export ENABLE_CCACHE
Note: be wary of ccache's own CCACHE_DISABLE environment variable: any
value (empty, "false" etc.) is considered a "true" setting for ccache
booleans (and so disables the program, falling through to real compiler).
Keeping all sources in one place
The Userland consolidation tools automate download of required source
tarballs. By older default they were kept in each component's directory,
but you could centralize it by using the 'USERLAND_ARCHIVES' variable.
Recently the defaults change to pre-initialize 'USERLAND_ARCHIVES' to
point into '$(WS_TOP)/archives/' unless customized by the caller - for
example, to share the common download area between multiple workspaces.
You can pre-set this variable in your user account '~/.profile' like
this (and note that the trailing slash is required):
### For oi-userland source files
USERLAND_ARCHIVES="$HOME/Downloads/"
export USERLAND_ARCHIVES
See also the 'make-rules/shared-macros.mk' for 'INTERNAL_ARCHIVE_MIRROR',
'EXTERNAL_ARCHIVE_MIRROR' and envvar 'DOWNLOAD_SEARCH_PATH' to get some
ideas about using HTTP mirrors to e.g. reduce network load and lags if you
can access a country- or organization-local mirror of opensource projects.
Component build
If you are only working on a single component, you can just build it using
following:
setup the workspace for building components
$ cd (your-workspace)/components ; gmake setup
build the individual component
$ cd (component-dir) ; gmake publish
Complete Top Down build
Complete top down builds are also possible by simply running
$ cd (your-workspace)/components
$ gmake publish
The 'publish' target will build each component and publish it to the
workspace IPS repo.
Tools to help facilitate build zone creation will be integrated
shortly. If the zone you create to build your workspace in does not have
networking enabled, you can pre-download any community source archives into
your workspace from the global with:
$ cd (your-workspace)/components
$ gmake download
You can add parallelism to your builds by adding '-j (jobs)' to your gmake
command line arguments. Note that if the host is constrained on resources
or the component source Makefiles are poorly thought out, parallel builds
can fail - in this case subsequent single-job (sequential) builds should
succeed to complete the missing build products.
It is worth noting that the OpenIndiana Hipster build server uses the
'COMPONENT_BUILD_ARGS=-j4' option by default for moderate parallelization
of its builds.
The gate should only incrementally build what it needs to based on what has
changed since you last built it.
Note that the project description data, including the texts, logos, images, and/or trademarks,
for each open source project belongs to its rightful owner.
If you wish to add or remove any projects, please contact us at [email protected].