Free portable sdk software for linux

CGI::Portable is a framework for server-generic web apps.

SYNOPSIS

Content of thin shell "startup_cgi.pl" for CGI or Apache::Registry env:

#!/usr/bin/perl
use strict;
use warnings;

require CGI::Portable;
my $globals = CGI::Portable->new();

use Cwd;
$globals->file_path_root( cwd() ); # let us default to current working directory
$globals->file_path_delimiter( $^O=~/Mac/i ? ":" : $^O=~/Win/i ? "" : "/" );

$globals->set_prefs( config.pl );
$globals->current_user_path_level( 1 );

require CGI::Portable::AdapterCGI;
my $io = CGI::Portable::AdapterCGI->new();

$io->fetch_user_input( $globals );
$globals->call_component( DemoAardvark );
$io->send_user_output( $globals );

1;

Content of thin shell "startup_socket.pl" for IO::Socket::INET:

#!/usr/bin/perl
use strict;
use warnings;

print "[Server $0 starting up]n";

require CGI::Portable;
my $globals = CGI::Portable->new();

use Cwd;
$globals->file_path_root( cwd() ); # let us default to current working directory
$globals->file_path_delimiter( $^O=~/Mac/i ? ":" : $^O=~/Win/i ? "" : "/" );

$globals->set_prefs( config.pl );
$globals->current_user_path_level( 1 );

require CGI::Portable::AdapterSocket;
my $io = CGI::Portable::AdapterSocket->new();

use IO::Socket;
my $server = IO::Socket::INET->new(
Listen => SOMAXCONN,
LocalAddr => 127.0.0.1,
LocalPort => 1984,
Proto => tcp
);
die "[Error: cant setup server $0]" unless $server;

print "[Server $0 accepting clients]n";

while( my $client = $server->accept() ) {
printf "%s: [Connect from %s]n", scalar localtime, $client->peerhost;

my $content = $globals->make_new_context();

$io->fetch_user_input( $content, $client );
$content->call_component( DemoAardvark );
$io->send_user_output( $content, $client );

close $client;

printf "%s http://%s:%s%s %sn", $content->request_method,
$content->server_domain, $content->server_port,
$content->user_path_string, $content->http_status_code;
}

1;

^The CGI::Portable class is a framework intended to support complex web applications that are easily portable across servers because common environment-specific details are abstracted away, including the file system type, the web server type, and your projects location in the file system or uri hierarchy.

Also abstracted away are details related to how users of your applications arrange instance config/preferences data across single or multiple files, so they get more flexability in how to use your application without you writing the code to support it. So your apps are easier to make data-controlled.

Application cores would use CGI::Portable as an interface to the server they are running under, where they receive user input through it and they return a response (HTML page or other data type) to the user through it. Since CGI::Portable should be able to express all of their user input or output needs, your application cores should run well under CGI or mod_perl or IIS or a Perl-based server or a command line without having code that supports each types individual needs.

That said, CGI::Portable doesnt contain any user input/output code of its own, but allows you to use whatever platform-specific code or modules you wish between it and the actual server. By using my module as an abstraction layer, your own program core doesnt need to know which platform-specific code it is talking to.

As a logical extension to the interfacing functionality, CGI::Portable makes it easier for you to divide your application into autonomous components, each of which acts like it is its own application core with user input and instance config data provided to it and a recepticle for its user output provided. This module would be an interface between the components.

This class has 5 main types of functionality, or sets of properties that exist in parallel but are fully/mostly independant from each other. As such, it could conceptually be split into 5 physical modules, some of which could be used on their own, but they are actually contained in this one module for simplicity of use (just one object for user code to keep track of). The 5 functionality sets could be called: Errors, Files, Request, Response, Misc.

Libconfig is a configuration file processing library that saves you from having to write your own configuration parsers and routines.
This project supports callback functions, automatic variable assignment, and many different configuration file types such as Apache-like, Windows INI-like, and whitespace separated.
Configuration is processed in a logical manner: global configuration files, local configuration files, environment variables, and finally command line options.
Enhancements:
- This release adds functions to set a user-specified error string from callback handlers.
- It exposes functions to convert from a string to a specified type.
- The documentation has been slightly cleaned up.

The goal of this project is to build a suite of free software tools to build and execute .NET applications, including a C# compiler, assembler, disassembler, and runtime engine.

While the initial target platform was GNU/Linux, it is also known to run under Windows, Solaris, NetBSD, FreeBSD, and MacOS X. The runtime engine has been tested on the x86, PowerPC, ARM, Sparc, PARISC, s390, Alpha, and IA-64 processors.

DotGNU Portable.NET is part of the DotGNU project, built in accordance with the requirements of the GNU Project.

DotGNU Portable.NET is focused on compatibility with the ECMA specifications for CLI. There are other projects under the DotGNU meta-project to build other necessary pieces of infrastructure, and to explore non-CLI approaches to virtual machine implementation.

Building

The three primary components of the system must be built in the following order: treecc, pnet, and then pnetlib.

You will need flex and bison to build DotGNU Portable.NET. We use flex 2.5.4 and bison 1.28. Some support is provided for the BSD version of yacc, but bison is recommended. Other versions of lex or yacc may not work.

Each source package can be unpacked, built, and installed in the usual manner:

$ zcat<<less