I had been searching through the ports list at Freshports, this morning – then researching a thesis with regards to audio/video file management on a FreeBSD Operating System (OS) – when I noticed an article denoting a couple of port utilities that I had not been immediately familiar with, namely portmaster and portupgrade.
Port Information Pages
The article that I’d noticed – conveniently enough – was an excerpt of the FreeBSD /usr/ports/UPDATING file, as presented via Freshports – no doubt, as presented as parsed from the file, in an application of something probably much like a regular expression matching any single name of a known port in the FreeBSD ports tree for presentation via the respective port information page onto the FreeBSD ports tree as presented at Freshports.
An Alternate Ports Management Tree
It would be a short segue from a thesis topic that I had wished to write about, this morning, to venture as to describe any manner of an alternative with regards to the “All the ports in one source tree” model as applied in the conventional ports tree. In a short synopsis, the secondary thesis might entail an application of something like an SVN externals and/or Git submodules structure, one for each port selected to a ports tree, if not also one for each distfile source tree, as could be linked newly within each port. Certainly, such a model would serve as to complicate the overall tasks of ports tree management, but – in localizing the possible changes for each port to the filesystem of each port submodule or port external – it might serve towards a greater sense of trust for maintenance of the ports tree, overall.
It may be a naive thesis – nothing immediately with regards to a situation as of, for instance, when one distfile may serve, functionally, as a source tree of multiple ports – such as, for instance, with each component developed of the Enlightenment Foundation Libraries (EFL), and each of those that is published as a port available in FreeBSD, all drawing from essentially the same distfile source tree, in any single revision of the upstream or distfile source tree for EFL. In Debian packaging – by contrast – it is possible to develop a model of “One distfile to many packages.” Such may also be possible in developing something like conventional FreeBSD ports, but it may require something of a differing source tree structure, such that one distfile may be referenced together with multiple ports, in a single port building tree.
Such a manner of an adaptaiton, of course, it might serve as to require something of an extension as with regards to the conventional port Makefile structures, as to adapt the Makefile process for the availability of more than one port together with a single distfile in any single port build container. Certainly, it would need a concrete proof of concept.
If it may not serve as to excessively complicate the configuration of individual ports, perhaps it might rather serve as to effectively merge the configurations of individual ports, at least for those ports which are produced, each, from a shared distfile – such as, for instance with the EFL components. Moreover, it might serve to prevent duplication of distfile contents for those ports presently deriving of an equivalent distifle. If only academically, it may seem like a trivial affair.
Towards a Functional Observatino of BSDPAN
Presently, this thesis article resumes as to share an observation about another topic, namely: The functional novelty of BSDPAN as a component structure effectively integrating PERL CPAN with the FreeBSD ports tree [Smith2008]. Perhaps it may serve as something of a reference model, with regards to integrating other “Third party” software distribution frameworks with FreeBSD – such as, Maven archetypes, OSGi bundles, CORBA CCM components, if not also pkgsrc ports. To develop a more comprehensive thesis, in such regards, perhaps it would need more than a short morning’s consideration.
Personally, I was not familiar with the existence of BSDPAN until reviewing the pkgtools.conf file installed with portupgrade.
Functional Points about Portupgrade
In itself, I think portupgrade is to a distinct attention with regards to software component management on a FreeBSD OS – that portupgrade provides some useful functionality, such that may serve as to be indispensable, immediately and prototypically, in tasks of systems administration.
In one regard, I notice portupgrade provides a means for ‘pinning’ ports, in a name-based regard – namely via the HOLD_PKGS configuration parameter – in a manner somewhat analogous to a package pinning methodology available with the Debian dpkg and apt/aptitude tools. Personally, I had been searching for such a feature, at an earlier time in my own experiences with a FreeBSD OS.
In another regard, portupgrade also provides an interface for defining event-oriented hooks, as viz a viz the following configuration parameters for portupgrade:
BEFOREBUILDBEFOREDEINSALLAFTERINSTALL
Also, there are useful shell commands that portupgrade provides, for example:
portsclean -CDLP # additional cleanup after port builds
pkg_deinstall -rR bad-mojo999 # dependency traversal
A Few Functional Observations About Portmaster
A small number of example applications of portmaster, beside the detailed documentation:
portmaster -s -y --clean-distfiles # noninteractive cleanup
portmaster --clean-packages # interactive
portmaster -a # update installed packages via ports
portmaster --list-origins # list all installed ports
portmaster --force-config coolutils/good-mojo777
Neat utilities.
A Topical Overview of Poudriere Applications
Of course, there’s also poudriere, such that provides a number of features for ports management onto the conventional FreeBSD ports tree. As a short, topical survey:
- Automated jail/sandbox creation for port building
- Port tree updating
- Port build configuration
- Port build automation
- Port build logging
- Package repository creation
- Numerous event-oriented hooks for the port build process
- Cross-compiling for ports on non-host machine architectures – e.g. armv6hf
If it does not immediately proceed so far as to automate a complete kernel build, base system build, and port buld procedure, but certainly it is an extensible framework.
Onto FreeBSD Make
As a central feature of the build process for (1) the FreeBSD kernel, (2) the utilities of FreeBSD base system userspace, and (3) the FreeBSD ports tree – together, the features of a FreeBSD OS, as a manner of a species of BSD OS – there is the contemporary manifestation of FreeBSD pmake as make, on a FreeBSD OS – ostensibly, such that might ever be obsoleted in lieu of portable bmake – however the contemporary FreeBSD make may have been forked from the original pmake, such that is now available as fmake, much in the complex genealogy of a BSD operating system.
Sure, it would be nice if a C toolchain would not be a mystifying thing or a developer to put together – how juxtaposing to the GNU Compiler Collection (GCC) and its species in each of a GNU Linux distribution, and FreeBSD, and MinGW, there’s also LLVM and its manifestations, such as in each of FreeBSD, the Qualcom Snapdragon platform, and LLVM on Debian GNU/Linux.
Concerning so much as the functionality of the build automation tooling of a conventional C toolchain: As well as the present state of each of bmake, pmake, fmake, and the current state of FreeBSD make, there’s also GNU make, i.e gmake. In some toolchains – for instance, with WebKit – moreover, cmake may be applied.
In the state of the art with Java toolchains, conventionally Maven, Ant and/or Gradle may be applied. Certainly, Maven and Ant were more the favorite, before the trend towards applying Gradle in Android Studio – needless to say that there are specialized software distribution processes for Java servlets, OSGI bundles, and JavaME MIDlets, specifically in a context of Java applications.
Build automation tools may be available for other programming languages, too – such a with each of Ruby, Lua, and Common Lisp. Even CORBA defines its own manner of a software bundling framework, in applications of the CORBA Component Model (CCM) – albeit, in what may be ostensibly a platform-agnostic component framework, CCM.
To a Developer’s Perspective, Funtionaly
Where, then, does that leave the independent software vendor? For all of the available toolchains and their respective applications, it may seem like a mystifying manner of a toolbox to even begin to understand.
This short survey of a thesis does no begin to address any single manner of a commercially branded software platform, such as Microsoft Visual C, Adobe Flash, or National Instruments (NI) LabVIEW. Neither does this thesis develop any single concept of an integrated development environment (IDE).
Beginning at a topic of FreeBSD ports, then proceeding towards developing a topic of the FreeBSD OS build process, lastly, in providing an overview about a number of software build automation tools – as are available in individual programming languages – perhaps this thesis may seem to go too broad, in scope.
Ostensibly, every software component denoted in this thesis may be modeled with a discrete, logical model, in a domain of software development – such that a logical model may be correspondingly applied as in a practical modeling application. Albeit, to model the commercially branded products, it might seem as though to encroach on any single manufacturer’s own intellectual property. Neither does this thesis propose as to encroach on the terms of any single, legally binding non-disclosure agreement.
Certainly, it must be possible for a construct of free/open source software to “Stand on its own premises,” as a feature of the state of the art in computing – if not, alternately, as a feature of the state of the market, as in so much of a competitive and commercial branding about software and software services, such as may be of a domain of commercial software productions.
Twoards an Analysis of FreeBSD Makefiles
Finding it as a manner of a scope to which to anchor a sense of perspective, the FreeBSD Makefile architecture may be introspected on, producibly, in analysis of the output of make -dv. In a functional regard, the output of make -dv represents a manner of a stack machine, namely o the Makefile interpreter as invoked with the make shell command. Effectively obviating a lexical analysis of Makefile syntax, the output may be analyzed for discovery of Makefiles as file objects, as well for discovery of Makefile parameter names, functional parameter value expressions, and final parameter values as computed by the respective Makefile interpreter.
Reviewing the FreeBSD Porter’s Handbook, in juxtaposition to the output of the Makefile debug stream, it may be possible moreover for any single software application to discover the complete configuration of any single FreeBSD kernel build, or singular base system build, or individual port build. Focusing distinctly about port builds, the values of specially named Makefile parameters may be analyzed for a purpose of discovering how individual Makefile parameters will effect the immediate dependency tree of any single port build in which each respective parameter is selected – viz a viz <OPTION>_<FEATURE>_ON and <OPTION>_<FEATURE>_OFF parameters, and ${PORT_OPTIONS:M<OPTION>} pattern expressions – such as may be defined in a port Makefile, independent of whether a single port configuration <OPTION> is selected at build time.
In the previous example, <FEATURE> may typically be defined as one of CONFIGURE, CMAKE, or QMAKE.
Makefile parameters affecting the value of CONFIGURE_ARGS: <OPTION>_CONFIGURE_ENABLE and <OPTION>_CONFIGURE_WITH
Makefile parameters affecting values of parameters applied in the Makefile environment, itself: <OPTION>_USE and <OPTION>_USE_OFF
Concluding In the Cloud
In a context of the contemporary cloud services environment, a sofrware build automation service may find applications not only in an academic sphere, but moreover in a creation of actual production systems from tangible build descriptors. In an application of a concrete build descriptor framework as in a context of a cloud service host such as IBM BlueMix, Amazon Web Services, or any single implementation of an Open Stack architecture, theotetically it is possible to construct a complete wide area network, such that may apply a lot of principal authentication services, hypervisor provisioning services, storage configuration services, software defined networking (SDN) services, and direct operating system management services, as to produce a functioning network, as well as a network management system, and any single range of software services as may be provided via the respective SDN configuration. Not as though to obviate any concrete analysis of software credentials, components, and services, in all of a theoretical convenience of such a modular framework, it may be possible to implement a trusted networking service in any context such as of DevOps tooling, scientific computing, or content management services.
In such a perspective, perhaps it may seem as like a manner of an excessive architecture, if applied for creating only a simple web log service for a sjngle web log. Thus, it may seem to ask a broader scope than of a single proof of concept as may be produced of the Hardpan Media Library – an academic project, of a kind, though not expressly non-commercial in all estimable applications. With the licensing of such a project amounting to no more than the sum of the licensing of its individual components, functionally – no manner of a premium, proprieatry branding included, immediately, in this as an application of logic, essentially as in a context of a thesis of computational sciences and digital network communications, applied in describing a manner of a software components model, albeit in a manner of a theoretical, if not singularly academic abstraction – it may not be as easily estimated that it could become to any single manner of an exclisively proprietary project, with or without any manner of a formal patent filing. Thus, albeit in something of a manner of a moderate vagueness, the GRANITENET architecture is introduced in a manner of an introductory thesis.
Hardpan Media 