Free program compiler installer software for linux

GUInseng installer is an installer for Linux, based on GTK+ and Glade, released under GPL. With Guinseng Installer you can create your own graphical installation packages for Linux.

It is not a replacement for package management like RPM or DEB, its just a GUI for installation or/and build processes. In most cases, you have already an installation program for your software - e.g. based on automake. GUInseng is just a wrapper around a ready installation program.

MetaC language extends C in a 100% backward compatible way with reflective features and techniques for refactoring, reconfiguring and modifying arbitrary C source code.
Therefore, the extensions provide special metadata types for working with source code information, syntactical structures for the definiton of code templates, and metafunctions to gather information about source code and refactor, modify, delete, or insert code.
Some of the modifications that can be done with MetaC, are also realizable with the C preprocessor. But the C preprocessor suffers certain limitations that can be overcome using MetaC.
The area of applications for MetaC is not limited to specific domains. But its concepts and its motivation has been derived from problems of CASE tools for embedded real-time systems (e.g. Mathworks Matlab, Telelogics Tau, Aonixs STP).
- Source code reconfiguration and refactoring in general.
- Abstraction of APIs and hardware-specific or vendor-specific implementations of well-defined functionallity (ever got locked to a specfic API by a RTOS vendor?).
- Source code instrumentation for WCET-analysis
- Adaption of source code to multiple embedded targets (especially differing native platform APIs) based upon an abstract machine model
- Application specific debug support (e.g. control-flow or data-flow tracing)
- Verification of domain- and application-specific constraints (e.g. MISRAs rules set for C based programs in automotive applicaitons)
Advantages of the Metaprogramming Approach:
- Source code modification is done based upon syntax. In consequence invalid modifications can be detected at the moment they are executed.
- Decision for code modifications can be made upon user parameters and information derived from the source code
- Crosscutting reconfigurations (i.e. reconfigurations concerning multiple functions or modules) of source code are possible.
Enhancements:
- Support for Win32 hosts was added.
- Support for initializer lists was added.
- Some C99 issues were fixed.
- Several more enhancements were made.
- A whole bunch of bugs were fixed.

Pod::Compiler can compile POD into an object tree.

This package, based on Pod::Parser, compiles a given POD document into an object tree (based on Tree::DAG_Node). It prints errors and warnings about the POD it reads. The result can be used to conveniently convert the POD into any other format.

The resulting objects have a variety of methods to ease the subsequent conversion.

There are two script based on this package, namely podchecker2, an enhanced POD syntax checker and podlint, which beautifies the POD of a given file.

This package is object-oriented, which means that you can quite easily build a derived package and override some methods in case the given behaviour does not exactly suit your needs.

Package Functions

The following functions can be imported and called from a script, e.g. like this:

use Pod::Compiler qw(pod_compile);
my $root = pod_compile(myfile.pod);

pod_compile( { %options } , $file )
pod_compile( $file )

Compile the given $file using some %options and return the root of the object tree representing the POD in $file. The return value is either undef if some fatal error occured or an object of type Pod::root. See below for methods applicable to this class and for the options.

The special option -compiler => class lets you specify an alternate (derived) compiler class rather than Pod::Compiler.

Compiler Object Interface

The following section describes the OO interface of Pod::Compiler.

$c = Pod::Compiler->new( %options )

Set up a new compiler object. Options (see below) can be passed as a hash, e.g.

$c = Pod::Compiler->new( -warnings => 0 ); # dont be silly

Pod::Compiler inherits from Pod::Parser. See Pod::Parser for additional methods.

$c->initialize()

Initalize, set defaults. The following options are set to the given defaults unless they have been defined at object creation:

-errors => 1

Print POD syntax errors (using messagehandler) if option value is true.

-warnings => 1

Print POD syntax warnings (using messagehandler) if option value is true.

-idlength => 20

Pod::Compiler creates a unique node id for each =head, =item and X, consisting only of w characters. The option value specifies how many characters from the original node text are used for the node id by the built-in make_unique_node_id method. See below for more information.

-ignore => BCFS

This option specifies which interior sequences (e.g. B< ... >) are ignored when nested in itself, e.g. B< ...B< ... >... >. The inner B is simply discarded if the corresponding letter appears in the option value string.

-unwrap => I

This option specifies which interior sequences (e.g. I< ... >) are unwrapped when nested in itself, e.g. I< ...I< ... >... > is turned into I< ... >...I< ... >. While some destination formats may handle such nestings appropriately, other might have problems. This option solves it right away. By the way, from a typographical point of view, italics are often used for emphasis. In order to emphasize something within an emphasis, one reverts to the non-italic font.

name =>

This is used to store the (logical) name of the POD, i.e. for example the module name as it appears in use module;. It is used internally only to detect internal links pointing to the explicit page name. Example: You compile the file Compiler.pm which contains the package Pod::Compiler. You set name to Pod::Compiler (there is no safe automatic way to do so). Thus if the file includes a link like L< Pod::Compiler/messagehandler > it is recognized as an internal link and it is checked whether it resolves. Of course you should have written the link as L< /messagehandler >...

-perlcode => 0

If set to true, the compiler will also return the Perl code blocks as objects Pod::perlcode, rather than only the POD embedded in the file. This is used e.g. by podlint.

$c->option( $name , $value )

Get or set the compile option (see above) given by $name. If $value is defined, the option is set to this value. The resulting (or unchanged) value is returned.

$c->messagehandler( $severity , $message )

This method is called every time a warning or error occurs. $severity is one of ERROR or WARNING, $message is a one-line string. The built-in method simply does

warn "$severity: $messagen";
$c->name( [ $name ] )

Set/retrieve the name property, i.e. the canonical Pod name (e.g. Pod::HTML). See above for more details.

$c->root()

Return the root element (instance of class Pod::root) representing the compiled POD document. See below for more info about its methods.

$c->make_unique_node_id($string)

Turn given text string into a document unique node id. Can be overridden to adapt this to specific formatter needs. Basically this method takes a string and must return something (more or less dependent on the string) that is unique for this POD document. The built-in method maps all consecutive non-word characters and underlines to a single underline and truncates the result to -idlength (see options above). If the result already exists, a suffix _n is appended, where n is a number starting with 1. A different method could e.g. just return ascending numbers, but if you think of HTML output, a node id that resembles the text and has a fair chance to remain constant over subsequent compiles of the same document gives the opportunity to link to such anchors from external documents.

Atlantis Installer is an installation wizard built to simplify installing PHP-GTK2 applications on multiple platforms as an alternate solution to using PEAR. Atlantis Installer allows you to build your application with the structure you want and drop it nicely as one package.

However not limited to installing PHP-GTK2 applications, this installer does require that PHP and GTK2 libraries be installed. To use this for non PHP-GTK2 apps, the end user would have first install the Gnope package (Windows) or install PHP, GTK2, and the PHP module manually (Linux). This is something someone looking to run PHP-GTK2 apps has probably already done, and hopefully in the future Linux distributions will come prepared for PHP like most do with Perl and/or Python.

The standard setup of the installer works like this. Upon launch it greets the user, prompts them to click next. Then it asks for the location the user would like to install, and then click next. It then installs the package and outputs the status live in the output box. Though configuration you can set default paths and change the look of the installer.

With scripting you can perform additional tasks during the actual install step (like if you need to chmod or rename a file). The installer automaticly checks if it can install to the directory the user specified, and if it can then it creates the necessary directory structure.

CMF Quick Installer Tool provides a a facility for comfortable activation/deactivation of CMF compliant products inside a CMF.
Therefore it has to be installed as a tool inside a CMF portal, where it stores the information about the installed products.
The requirements for a product to be installable with QuickInstallerTool are quite simple (almost all existing CMF products fulfill them):
.External Product: The product has to implement an external method install in a python module Install.py in its Extensions directory.
.TTW Product: The product has to have a Install folder and have a python script titled install inside that folder.
Products can be uninstalled and QuickInstellerTool removes the following items a product creates during install:
.portal types
.portal skins
.portal actions
.portalobjects (objects created in the root of the portal)
.workflows
.left and right slots (also checks them only for the portal)
Attention: QuickInstallerTool just tracks which objects are ADDED, but not what is changed or deleted.
second Attention: QuickInstallerTool just can uninstall products that are installed via QuickInstallerTool
Enhancements:
- Adjusted installProduct method to be compatible with CMF 2.1
- Refactored ResourceRegistries support not to require the product itself to be installed in QI.
- Added the INonInstallable interface that is used to look up utilities.
- Added an option to omit snapshot creation which defaults to True to speed up.
- We automatically create a GenericSetup snapshot before and after installation.

Plugin::Installers goal is to provide a simple, flexable interface for developing plugin languages.

SYNOPSIS

package Myplugin;

use base qw( Plugin::Installer Plugin::Language::Foobar );

...

my $plugin = Myplugin->construct;

# frobnicate is passed first to Plugin::Installer
# via AUTOLOAD, then to P::L::Foobars compile
# method. if what comes back from the compiler is
# a referent it is intalled in the P::L::F namespace
# and if it is a code referent it is dispatched.

$plugin->frobnicate;

The goal of this module is to provide a simple, flexable interface for developing plugin languages. Any language that can store its object data as a hash and implement a "compile" method that takes the method name as an argument can use this class. The Plugin framework gives runtime compile, install, and dispatch of user-defined code. The code doesnt have to be Perl, just something that the object handling it can compile.

The installer is language-agnostic: in fact it has no idea what the object does with the name passed to its compioer. All it does is (by default) install a returned reference and dispatch coderefs. This is intended as a convienence class that standardizes the top half of any plugin language.

Note that any referent returned by the compiler is installed. Handing back a hashref can deposit a hash into the callers namespace. This allows for plugins to handle command line switches (via GetoptFoo and a hashref) or manipulate queues (by handing back an [udpated] arrayref.

By default coderefs are dispatched via goto, which allows the obvious use of compiling the plugin to an anonymous sub for later use. This make the plugins something of a trampoline object, with the exception that the "trampolines" are the class methods rather than the object itself.

Scriptol to binary Compiler is a C++ native compiler.

Installation:

It is better to install Scriptol at root of a disk, for example:
c:scriptolc

Once the archive is extracted into the scriptolc directory, you have just to change to this directory to run the compiler.

To use the compiler at command line from any directory, you have to put the compiler into the path variable.

The setup script installs required file into sub-directories, or into the directory given as argument. Before to use the compiler, you have to read the licence, in the doc
directory: licence.html.

Usage:

Just type:
./solc mysource

Type "solc" only to list the options.

If your program is a multi-file project, the source given as parameter must be the main source file, the compiler will know dependencies from "include" statements and will build what is needed.

Exemples:

Type from the main scriptol directory:
./solc -bre demosfibo

Configuring:

By editing the solc.ini file, you may change the second pass compiler (you may have to rebuild the libsol library for this compiler), change the options of the compiler or add header files to include.

To add header files, just add "header=someheader.hpp" lines into the config file.

A xxx.cfg file may be written for each project main source beeing xxx, and if present, it overloads the solc.ini file.