CONFBASE

Home |FAQ |License |Rules |Configure |Build |Test |Track |Resources |Archives
CONFBASE
CONFBASE is designed as a knowledge base forsoftware configuration. It not only configures a piece of software on a target platform but helps the developer active in porting software on new platforms or resolving errors which arise if a software is used on platforms the programmer didn‘t intended it for. The knowledge base keeps all information of a configuration problem and helps to detect and solve the same problem in new software projects and platforms.
Advertisement
How To Copy Any Dvd With A CD Burner!
Make perfect copies of your DVDs. Be able to burn any DVD movie onto a Cd using any Cd burner! Download Now!
Master Resell Rights,Ebooks,Software!
For Entrepreneurs and Home Biz web owners - we provide ebooks, software, audio/video products - complete with sales websites, for each product and program.
PSP Software.
Over 20 Million Items. Unlimited Downloads. Games, Hacks, Cheats, homebrews, Software, Movies, Upgrades, Simulators, Wallpaper, Database Updated Daily.
Anti-Virus Software
Get the latest info on anti-virus software.
The knowledge base contains mainly the following types of objects:
Symptoms
The error message of the compiler, or the behavior of the program, which makes you, notice that you have a problem. If you get the same symptom in a different program you may have the same problem and can use the same solution.
Causes
The lines of code, which are responsible for the problem. Or the compiler switch that doesn?t exists on all platforms, etc. If a new project has the same lines, it will probably need the same config solutions for different environments.
Probes
How can be checked on which platform we are, which compiler exists and which compiler switches are supported? In one sentence, what environment we are configuring for. Probes are discussed in more detail later.
Solutions
The piece of code, which can be used as a replacement to run the software on a new platform. Or which is generic to be used on more than one platform. This will be detailed later.
Relationships
What are the relations between the objects, which probes must succeed to justify the application of a solution or other probe?
Problems
A general description of  a problem which occurred. For one Problem may exists more than one solution. Problems are also called config cases.
Environments
That?s what?s describes what we have or don?t have. I.e. the platform, operating system, programming language, architecture, build tool, etc. The environment contains all the details (up to version number) which make configuration necessary.
CONFBASE is designed as an open Framework. It sets the standards, which objects exists, how they interact together, how they can be viewn and modified by a graphical user interface and how they are applied and distributed in programs. But it is previewn and expected that users add new object types, which respect the object standards to enhance the usability of CONFBASE for certain projects or programming language. In other words, CONFABSE defines the class interfaces and provides a set of classes which implement these interfaces. Instances of these classes are created for a concrete configuration problem. New classes, which implement the class interfaces can be added to adapt to special needs.
With these information of a config case the tool can help in the following situations:
The tool probes the environment on which a software is going to be installed. The result of the probes is used to selects the right solutions for this environment to solve all know config cases.
A programmer can adapt his software to be multi platform conform by adding generic solutions from the knowledge base to his program. The causes in the knowledge base give him hints which parts of his software may not run on a different platform. So he must not be an expert of the target platform. The CONFBASE gives him all the knowledge he needs to port his program.
A user got software that doesn‘t runs on his platform. The symptoms in the knowledge base help him to find out which problem he has and which solution could be applied.
Files of CONFBASE
CONFBASE is separated into three files. An executable named «confman» and a database called «confbase» with all the configuration cases and related information. If this is a real database, a flat file database or just a collection of class files can be decided later by the implementer. The ?confbase? database may be located on your local machine, on a server in an intranet or the internet. Programs configured with CONFBASE are delivered with a file called «confscript» which contains all the information needed to configure this program. So if I only want to configure and build a program on my machine I only need the program and confman. If I want to port a program to a new environment I further need access to a confbase. I also need the confbase if I want help from CONFBASE to fix a failing build of a program.
Detailed description of the CONFBASE objects
What is an environment?
The environment is the hardware and software you use or your program is intended to run on. As a program must cooperate with other software (for example with the operating system) it must be able to serve the adds and odds of every piece of software and hardware his programmer wants it to run on and even a user wants to run it on. There are some "standard" values, which can be used to describe an environment.  These are operating system, machine type, bus architecture, programming language, build tool etc.
But to describe an environment completely much more values must be considered and described.
This tool defines an environment by the names of all the probes that must be fulfilled in this environment. In other words the names of all probes which succeed on your computer are the environment you are working in.
To structure an environment the config problems, solutions and probes are ordered in a hierarchy. Some probes make only sense if other probes already succeeded. I.e. it makes only sense to probe the type of linux distribution if we are on a computer with the linux operating system.  Other probes in the hierarchy do not really probe anything but are just for documentation and structuring.
We say that a probe is dependent of another probe if the probe makes only sense if the other probe is fulfilled. These dependencies are relationships and are stored in the probes. An example of a probe hierarchy is: operating system family (Windows, Unix, Macintosh), operating system (Linux, AIX, Solaris, ...), Distribution (SUSE, Red hat, Caldera), Version (6.1, 6.2). Other main branches of the environment are:
Programming language: C,Python, Eiffel, Scheme,...
Architecture : Intel, PowerPC, Alpha, ...
Build Tool : make, ?, (the build tool resulting from this competition)
Problem Domain :Network, Graphic, Filesystem, GUI, Sound, ...
Applicationtype: Enduser (Subbranch Text, Graphic, Database, ...), System, Development, ...
Device : CD-ROM, Harddisk,Scanner, Graphic card, ...
Window System, X11 (SubBranch Window Manager : Gnome, KDE, ...), MSWindows, Macintosh
Some of these probes are just descriptive to structure the probes and solutions. This is for example true for « Problem Domain  and Application type».  Most of the main branches will have further sub branches. CONFBASE will have a useful set of branches by default. Users can add other branches as needed.
The branch «Application type» has a special usage. At the leaves of this Branch are all projects configured with CONFBASE and all probes and solutions that are specific to a Project will be connected to this branch. Generic solutions will be found in the other branches of the environment.
A probe and solution is not limited to one branch in the environment but can be found probably under every main branch of the environment. So an environment is not a tree but a directed network - anyway this doesn?t changes anything important.
Environment are defined and can be computed via the relationships between probes and solutions. As they can be computed there is no need to store them explicitly in the confbase. But it is easier to understand the overall concept if environment are seen as objects.
Solutions
Solutions depend on some probes, which must succeed to be able to apply a solution. Every probe returns a result value. In the definition of a solution you can enter which probe result values the solution needs internally and under which name the solution wants to access this result value. If the result of a probe is a Boolean value you rarely want to access this value in the solution, as it will always be true - otherwise the solution would not be applied. On the other hand  - a probe, which returns a path to a file, here your solution, may needs the path and specifies it in the solution interface. Other solution may not care about the location, they only want to be sure that the file exists.
The solution part is divided into a static and a dynamic part.  The static part is independent of the environment and can already be applied to a project before delivering the project. The dynamic part is dependent of the environment and is applied to the program after evaluating the environment with probes. The static part must be applied by hand to a program and is just a text file with a piece of source code and a description how and where to insert this code into a project.  The static solution also includes a mark, which uniquely identifies this solution. The mark is used to detect all solutions applied to a program and is thus the basis for the automatic configure script creation. The mark also avoids that a search for configure problem causes in a program detects the solution as a possible problem.
The dynamic solution part is applied automatically to a program and there are some standard types. Other types can be added easily as needed. The following standard types are previewn:
- diff between two versions of a file
- patch to a file or directory
- setting of a key value pair in a dictionary
- copying of a file
- creating a symbolic link
- replacing of text in a file
- executing a python function
- executing an expect or pipe script (both can be created with autoexpect or autopipe, which allowes creating solutions with minimum programming knowledge)
- executing an external program.
The aim of the static solution should be to realize a programming interface which encapsulates the configure problem and hides it from the programmer. In any environment the programmer can use the same API and has not to bother about details. How this API is realized, by preprocessor directives as usual in C, by importing different modules  as the OS Module in python or by creating a subdirectory for each environment and changing the include path (in the dynamic part of the solution) - this decision is left to the programmer and no style or new syntax is forced by CONFBASE. The programmer can decide which method is the best for the project and used programming language.
Symptoms and Causes
Symptoms and causes are parts of a solution. Solutions can have more than one symptom and cause, if they are very generic.
Symptoms are stored as plain text and as search pattern (perl regular expression).
The cause and the solution overlap, as the solution must contain different code for each platform it supports and obviously this code is the cause of failure in other environments. But causes are stored as regular expressions, they will match better and more realistic problematic code.
Probes
See building new probes.
Relationships
Between probes itself and solutions relationships are defined. This has two functions. First to structure the mass of probes and solutions into a hierarchical representation, which can be easier, navigated and understood. Second to assure that solutions are only applied if all conditions are matched which they need to run and which justify their application.
So every solution and most probes have some probes on which they depend and a "Dependency" is defined between them.
a "Replacement" relationship is used for version control and signifies that a newer or better version of a probe exists and the old one should not be used in new projects.
Inteface to build tools
CONFBASE will distinguish different build tools. That?s why solutions can only set key value pairs in a  dictionary. Depending on the configured build tool this dictionary is transformed into something understood by the build tool. (i.e. preprocessor variables for make)
Using CONFBASE
Confbase may have different user interface (raw text, curses, graphics) similar to the linux kernel configuration system. In the following, for brevity,  only the graphical interface is described as it is the easiest to use and should be used the most widely.
Example 1
Situation: You got software out of the Internet, which is prepared for multiple platforms by CONFBASE. You want to compile it on your machine.
To do so you need the CONFMAN executable on your machine as you need a compiler and a build tool to compile the software later. You don‘t need the CONFBASE knowledge base on your machine. Instead the software which you want to compile and which was prepared with CONFBASE is delivered with a confscript which contains all the information (probes and solutions) to configure this software.
You start the script delivered with the software, which starts the CONFBASE tool, or you start CONFBASE and specify the script as parameter.
The tool opens the "Probe environment" window. In this window you see all the probes needed to configure the software for all prepared environments. As the probes are arranged according their hierarchy you just see the first level of the hierarchy and by clicking on a probe you can see the probes which depend on the selected on. This is the same as the directory hierarchy (tree) of a file manager.
In 99% of the cases you would now just click "Start probing" to run the probes on your machine to collect the results of the probes. But you also have the choice now to:
-          Load a probe result file created on your machine to avoid retesting and speedup the probing phase and set standard values .for « ask user » probes (explained later).
-           Load a probe result file created on a different machine to do "cross-configuration"
-          Set the result of some or all probes by hand to emulate a virtual environment or test the probes and configuration for a different environment.
At this point I want to explain that a type of probe exists which is called "ask user", which  doesn‘t detects anything itself but simply asks the user for the correct result. This sort of probe is intended for: installation directories and installation options (with debug information, syncron - parallel, etc.) or any other thing which depends on the users preferences and taste and not on the computer environment.
If such probes exists in the project, a screen is presented to the user with all « ask user » probes and the default values for the probes. The user can now accept the default or change to his taste. Help is available in form of lists of valid values for a probe with a limited range of values and example values for probes with unlimited allowed values.
Once everything is fine the user clicks « OK » and automatic probing goes on.
After all probes have been done you see again the "probe environment" window with the probe hierarchy and know added to each probe the result of the probe. Again you have the possibility to change results by hand  (which is rarely useful) until everything corresponds to your favors.
At the leaves of the environment hierarchy are the solutions which will be applied if the probes before the succeeded.
You know click the "Start Config" button, which applies the problem solutions to the program corresponding to the results of the probes. The configuration is now finished and you start the build tool to compile the program.
In the case that a probe failed you see these probes at the top in the « probe environment » window. You may decide to set the values by hand or just go on and try to build anyway. If the build then fails you can go on as described in the following example.
Example 2
Situation: same as example one but with the addition that the configuration fails, i.e. you get errors when you try to build the program. You now want to fix the errors to get a running program.
In this situation you also need the CONFBASE knowledge base installed on your machine or accessible via a network.
You save the error message of the build tool somewhere and then start CONFBASE. You select the "Analyze symptom" menu point and when asked to enter the symptom you enter the error message of the build tool. Then you see again a window with an environment hierarchy and you can if you want limit the symptoms searched in the 7knowledge base by specifying the environment to be searched. For example it makes less sense to search C compiler error messages if you have problems with a Python program. If you are unsure about the environment you don‘t select anything and start the search with the "Search" button.
The Tool presents you the entries in the knowledge database with matching symptoms and now you must decide if you have an identical problem, or if a new problem arised in your environment for which not jet a solution exists in the CONFBASE knowledge database.
If the symptom search didn‘t helped and the error message contains a line number of the code which caused the error you can make a second search on the cause entries in the knowledge database. You select the "Analyze cause" menu point and enter when asked the lines of code (or the whole file) addressed in the error message. Here also you can limit the search space by describing the environment but you are not obliged.
If you find a solution to your problem by either symptom or cause you follow the instructions in the solution description and your program should work now.
if neither helps you can try to make the program generally more portable as described in Example 4. Otherwise you are on your own and CONFBASE will be useful only again from the moment where you found a solution and want to integrate it into the program or in the knowledge base of confbase.
Example 3
Situation: You had a problem with a program and you created a new solution to this problem and want to integrated this solution into CONFBASE.
Start CONFBASE and select "New Case" from the main menu. Confbase will ask you for a Problem Name, a Problem Description, the symptom of the Problem and the Causing code of the Problem. Enter everything appropriate. The symptom is the error message of the build tool which made you notice that you have a Problem and the causing code is the piece of code you had to change to make your program run. Both are entered as plain text and as regular search expressions.  For both you also have to enter the environment in which they occur. For the cause, this is the environment in which the causing code works, so not your environment. For the symptom its the environment in which the symptom can be seen, so this is your environment. Both environment should not be given to detailed. The programming language and the operating system should be sufficient.
The next thing you have to enter is the solution to the problem you have created. CONFBASE splits the solution in a static and a dynamic part. The static part is independent of the environment and can already be applied to a project before delivering the project. The dynamic part is dependent on the environment and is applied to the program after evaluating the environment with probes. The static part may be a C source file where the code for different environments is separated by preprocessor commands. In this case the dynamic part is just the setting of the preprocessor variables to the values of the environment found.
In other cases the solution may only have a dynamic part - a patch file which is applied to the standard source tree of a program.
After entering the solution you will be asked for the probes which describe the environment where this solution is needed. Select the probes from the probes hierarchy window or create a new one as described later. If your solution expects other solutions already applied you can add these solutions as dependent too and thus force the execution order. The config case is now finished and ready for publishing.
From the main menu select "New probe". Give a name and description to the new probe and select the result type of the probe (boolean, element of a list, file or path name, etc.). If the result space is a limited list of values, enter all of them in the allowed values field. If the result space is unlimited, give some example values in the example field. Also give a default value which is right in most environments.
Then you can select the type of probe you want to create. There are some standard types available from the beginning:
- locate a file
- find a text or pattern in a file
- execute an external program
- execute a python function
- run an autoexpect/autopipe script ( autopipe is an implementation of expect and autoexpect in python, it is the easiest way to build a script which runs external programs and verify that the output is always as expected.)
- build a combination of other probes (logical connected by "And" or "Or".
- lookup a MS Windows registry value.
- run a m4 macro from the configure program nowadays widely used.
All probe types implement a standard class interface so it is easy to add later new types of probes to the tool. Especially programming language parser, which allow finer location of search pattern are a valuable extension. So you could not only limit the search to a file, but directly to a function or type definition. As such parser are not only useful for a configuration tool but of general interest (for example in editors) they are not listed as standard types here.
To build a new probe you select the type of probe. Depending of the probe type a dialog window popes up which asks for the other values needed by this probe type. (i.e. filename, pattern)
Last you add dependencies to your probe. Which probes must succeed before your new probe makes sense. The probes your probe type itself needs to execute, due to references to external programs, are added automatically. But you may want to add some further if you use some other external programs in your new probe.
Your probe is now ready for usage and publication.
Example 4:
Situation: You wrote a program and want to make it portable to other platforms. Also you want to add a confscript to your program.
Start confman and select  ?Check portability? from the main menu. Confman asks you for the names of the files to check and opens a dialog with a listbox and filebrowser. Drag all the files you want from the filebrowser to the listbox. If you select a directory all files and subdirectories are added also. If you have selected all files press the ?Next? button. You see the ?environment hierarchy? window titled ?source environment? and must limit the environment to the platform your program supports at the moment. You don?t need to be 100% exact here. If you select the computer language and the operating system it will be ok for most applications. Confbase later searches causes in the confbase which match your source environment. Only these causes are compared against your source files. If a match is found this may be a configuration problem and will be presented to you.
After selecting the source environment click ?Next? and again an environment window is shown, this time for the target environment. For a quick start leave this untouched (you can return later), otherwise select the targets you want to support. Again, selecting the language and operating system, or any other branch (Window Manager, Database System) will be enough. Click the ?Start Check? button. CONFBASE will now scan all the files for text, which matches causes in the confbase which are known to exist in the source environment. The matches will be splitted into three groups. The first one will contain all matches from causes, which stay inside the target environment. The second group contains matches where the target environment is not covered by the causes but where solutions exist. The third one are problems without solutions.
Causes have an environment that describes on which platform these causes can be found. This environment is a partition of the environment of the solution, the cause belongs to. If a cause environment covers the source and target environment given it is not a problem here and doesn?t needs any configuration or source code changes. If the cause environment covers the source environment but not the target environment and the solution of the cause covers the target environment we must add this solution to our program. If the target environment is covered neither by the cause nor by the solution we may have a configuration problem but no know solution. But it may also be the case that the environment of the cause and/or solution is specified to limited. The user can investigate for these cases further by consulting an expert. A good choice is to ignore these matches.
The results are presented on the result screen to the user. Only one group is visible at the same time (by default the second) and the user can switch the groups with notebook tabs. With the button ?refine target environment? the user can change the target environment again, which will result in a regrouping of the matches but not in a new search.
Next to the list of results is the details window which shows information about the cause and solution and a third window for the source text matched. The user can now investigate one match after the other. He can choose to order the matches according to the environment hierarchy or the position of the matches in the source files. For each match he must decide if the match detected is really a problem or was a wrong alert. If it is a real match he will follow the solution description and change his source code. This can be done directly in the confbase tool or in his favorite editor. Together with the solution the mark of the solution is added to the source code too. The marks allow to detect automatically which solutions are integrated into a program and which probes are therefore needed.
If a match is an unjust alert the user can modify the cause definition to avoid wrong alerts under the same circumstances again.
Once all matches are rejected or applied the user got a higly portable program. The last thing to do is to create a configure script.
Example 5
Situation: A program was made portable or just modified and a new confscript must be created.
This is one of the easiest things. Start CONFBASE and select ?Build confscript? in the main menu. In the opening dialog select all the files which are part of your project. Press ?Create?. CONFBASE now searches in all given files for marks of solutions. Each mark found means a solution was applied. As solutions have dependencies to probes CONFBASE also knows which probes must be used. So CONFBASE automatically creates the configure script with all the dynamic parts of the solutions, all the probes, the names of all selected files and any other data needed. As probes are ordered hierarchically the probing order is clear to. If a user wants to add solutions by hand, he creates an empty file and inserts the marks of the solution he wants to add. If this file is added to the selected file list, the solutions are added to the confscript to.
If a user wants to refresh an existing confscript, the list of used files can be taken from the old file so a selection of files is not necessary again.
If one of the selected files is a confscript, this will not be searched for marks, but integrated into the master confscript and be seen as a subproject of the project. In addition the user can choose if a subproject is optional (for example the configuration for the build of HTML documentation) or required (for example a library). If more project management capabilities are needed, an integration with the build tool is appropriate instead of reinventing the wheel again.
Version Control
To keep version control simple and to be able to guarantee that old projects will always work whatever and whoever changed a solution or probe. Objects in CONFBASE are unchangeable. If you want to change something you have to create a new object. Of course you can start with a copy of an already existing object. Between objects exists a special dependency "replacement" which is used to document that a new Version of an object exists and the other object should not be used anymore for new projects. The tool will hide the unchangeability of the objects most of the time in front of the user. So when I wrote in this concept that an object can be adapted or changed, internally a new object is created.
2005 Copyright software-carpentry, All rights reserved