OpenMake Meister – OpenMake Meister

Blog: Software Build Automation Done Like Google Rock Stars

Mon, 27 Sep 2021 00:00:00 +0000

Software Build Automation Rock Stars at Google.

Build Automation is what OpenMake Software has survived on for the last 20 years. It is core to your software development efforts regardless of what kind of development you do - agile or waterfall. Software build automation covers all aspects of compiling and linking your software application and making sure it can support continuous delivery - knowing the readiness of any software builds.

Managing Dependencies

Software Build Automation includes managing software dependencies, executing incremental builds, accelerating builds, exposing analytics, showing implosion and explosion reports and simplifying the entire soup to nuts process. Most companies use scripts. We use standardize playbooks we call Build Services. These Build Services standardize how compilers are called creating builds that are reproducible. Google has some tips as well that I thought was worth the time seeing.

Watch this Google video from their education series.

https://www.youtube.com/watch?v=2qv3fcXW1mg

They have written a homegrown process that is extremely similar to Meister. Build Rules, the elimination of scripts, incremental processing, management of libraries, parallelization and distribution of workload is all shown. The good news is you do not need to write this process on your own. You can use Meister instead. Meister solves all the problems and provides all the features covered here. So yes, your builds can be intelligent too.

And best yet, Meister is free for small teams and can be downloaded from https://github.com/OpenMake-Software/Meister/releases/

Blog: Complex Compiler Plugins for OpenMake Meister

Wed, 30 Jun 2021 00:00:00 +0000

Compile Plugins for Adobe, Lawson, Cognos, and Others

Meister allows you to add 4GL and Mobile compile requirements to your build automation using plugins.

Name	Description
Lawson	Compiles Lawson objects using the Lawson compiler in headless mode.
Adobe Flex	Compiles Adobe Flex objects.
PeopleSoft Cobol Native Runtime	Creates MicroFocus COBOL generated native code (GNT) files from COBOL files. The target extension is '.gnt' and the source files are either .cbl or .cob. The flags chosen come from the pscbl.mak script that comes with PeopleSoft on UNIX.
PowerGen	Creates an executable from PowerBuilder project using PowerGen.
Actuate6	Reports Actuate6 report compiler. Creates and .rox
Cognos Powerhouse Compile Takes	Cognos Powerhouse files (.qzs, .qks, .qts) and passes them to their respective compilers. Then it prints both the input passed to the compilers and the output of each of the compilers to a .cognos_log file.
Informix 4ge Executable .4ge	Creates an executable target from Informix and c code using the c4gl compiler. It is broken into two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and .a archive libraries to create the Final Target executable.
Informix Archive Library	Compiles source code with the c4gl compiler and bundles the objects into an archive library using the GNU ar program.
Informix 4ge Executable	.4ge Creates an executable target from Informix and c code using the c4gl compiler. It is broken into two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and .a archive libraries to create the Final Target executable.
Informix Form Compiler .frm	Creates an Informix form target from .per files using the form4gl compiler. There is only one task which compiles .per files into .frm files.
Informix noext Executable .noext	Creates an executable target from Informix and C code using the c4gl compiler. It is broken into two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and .a archive libraries to create the Final Target executable.
Informix Object	Creates an object target from Informix or C code using the c4gl compiler.
Informix Shared Library. .so	Creates a standard shared library using the gcc program.

Support Database Management in Your Software Compiles

Meister enhances build automation by allowing you to incorporate database updates in your compile logic. The following Plugins can be purchased to extend your library of reusable Build Tasks.

Name	Description
Oracle Cobol Exe	Creates a standard executable linked statically and dynamically with Oracle libraries. For pre-compiling, it calls the Oracle proc program. For C and C++, it executes the xlc compiler. For COBOL programs, it uses the Microfocus COBOL compiler, cob. For creating the executable, it uses the Microfocus COBOL compiler, cob, to link.
Oracle Exe	Creates a standard executable. For pre-compiling, it calls the Oracle Pre-Compiler. For C and C++, it executes the cc compiler. For creating the executable, it uses oraxlc to compile and link.
Oracle Forms	The Oracle forms compiler, ifcmp60 on Windows and f60gen for other OS's, is used to create form objects from .fmb files.
Oracle Form Library	The Oracle forms compiler, ifcmp60 on Windows and f60gen for other OS's, is used to create form libraries (.plx) from .pll files.
Oracle PSQL	Compiles PL/SQL into an Oracle database. A file with .sqo extension is created to represent a successfully compiled object on the file system. The timestamp of the dependency .sql files will be checked against the .sqo file for incremental builds. If the .sql file is later than the .sqo, then it will be recompiled and a new.sqo file created. sqlplus is used to compile the code.
Oracle Report	Uses the Oracle Reports compiler, rwcon60, to create .rep reports. .rdf files may also be created.
Oracle TDF	Uses the Oracle Reports compiler, rwcon60, to create TDF reports. .rdf and .rex files may also be created.
Oracle Request Router	An example of a customized Oracle C and C++ executable. It uses xlc/xlC to compile source code and ld to link the objects into an executable.
Sybase ASE 12.5 and Greater	Used to create Sybase Adaptive Server database objects. It uses files to represent compiled objects and uses the isql program for compiling DDL, SQL and T/SQL. It uses the bcp command to import and export data. Designed for use with ASE 12.5 and greater. Beginning in ASE 12.5, ALTER statements can be bundled in a single transaction. You must have the "use ddl in tran" option set to true. To set this, issue the following commands at the Sybase command line: use db_name go sp_dboption db, "use ddl in tran", true go Start by create a final target file name with '.complete' extension. The name can be anything and can be related to a change request, e.g. SCR0345.complete This file will be created only after all the operations have completed successfully. Then add individual file dependencies broken down into single files as dependencies in the different option groups. Note that different types of DDL statements must have different file extensions according to the rules.
Sybase ASE pre-12.5	Used to create Sybase Adaptive Server database objects. It uses files to represent compiled objects and uses the isql program for compiling DDL, SQL and T/SQL. It uses the bcp command to import and export data. Designed for use with ASE prior to release 12.5 because of the inability to bundle multiple ALTER statements into a single transaction. You must have the "use ddl in tran" option set to true. To set this, issue the following commands at the Sybase command line: use db_name go sp_dboption db, "use ddl in tran", true go Start by create a final target file name with '.complete' extension. The name can be anything and can be related to a change request, e.g. SCR0345.complete This file will be created only after all the operations have completed successfully. Then add individual file dependencies broken down into single files as dependencies in the different option groups. Note that different types of DDL statements must have different file extensions according to the rules.
DB2 Exe	Creates a standard executable by using DB2 Prep to pre-compile the .SQC file. Uses cc to compile the C programs. Uses xlc for linking.
DB2 shared library	Creates a standard shared library by using DB2 Prep to pre-compile the .SQC file. Uses cc to compile the C programs. Uses xlc for linking.

Linux and UNIX Compile Plugins for Complex Builds

Meister’s Extended Plugins for Linux and UNIX compile needs support complex compilation tasks and includes your dependency management and acceleration. The following Plugins can be purchased to extend your library of reusable Linux and Unix Compile Plugins.

Name	Description
AcuCobol 32 Executable	Creates a standard executable using the AcuCOBOL CCBL or CCBL32 compiler.
Archive Library	An archive library is created by compiling source code into object files and the bundling the object files with the ar program.
Microfocus Cobol Executable	Creates a standard executable. For C and C++, it executes the xlc compiler. For COBOL programs, it uses the Microfocus COBOL compiler, cob. For creating the executable, is uses the Microfocus COBOL compiler, cob, for linking.
COBOL Native Runtime	This creates MicroFocus COBOL generated native code (GNT) files from COBOL files. The target extension is '.gnt' and the source files are either .cbl or .cob. The key flag is the '-u' flag which tells the compiler to create a GNT file instead of a native operating system object file.
GNU Archive Library	Compiles source code with the gcc compiler and bundles the objects into an archive library using the GNU ar program.
GNU CPP Executable	Creates an executable target from .c code using the gcc compiler. It is broken into two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and libraries to create the Final Target executable.
GNU Executable	Creates an executable target from .c code using the gcc compiler. It is broken into two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and libraries to create the Final Target executable.
GNU LD Shared Library	Creates a standard shared library using the gcc or g++ programs to compile C and C++ code and then using the AIX ld program to link the objects into a dynamic library.
GNU Oracle ProC Executable	This creates an executable from source code by compiling the C code and linking to Oracle libraries.
GNU PIC Archive Library	This creates a GNU archive library from source code by compiling the C/C++ code with the Position Independent Code option of the gcc compiler.
GNU PIC Executable	This creates an executable from source code by compiling the C code with the Position Independent Code option of the gcc program.
GNU PIC Oracle Executable	This creates an executable from source code by compiling the C code with the Position Independent Code option for gcc and linking to Oracle libraries using gcc.
GNU Shared Library	Creates a standard shared library using the gcc program.
ITHISAM	Creates C header files from .DDL using the ITHISAM compiler.
LD Shared Library	This shared library explicitly uses ld in the Link Build Task. The shared library is created by using the ar command to format the final object. cc is used to compile the source code.
LD Shared Object	This shared library explicitly uses ld in the Link Build Task. The shared library is created WITHOUT using the ar command to format the final object. cc is used to compile the source code.
Lex and Flex C File	Used to generate a C source file from a lex source file when the C file needs to have a different name from the Lex file. There is also a Build Task under Available Tasks with the same rule that can be imported into any build service that compiles C code.
Lex C Header File	Used to generate a C source header file from a lex source file when the C file needs to have a different name from the Lex file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.
Visual Age C Project Archive Library	Creates an archive library from the .icc project file. The .icc files is scanned to see if any source code has changed compared to the executable being created.
Visual Age C Project Executable	Creates an executable target from the .icc project file. The .icc files is scanned to see if any source code has changed compared to the executable being created.
PIC Archive Library	This creates a GNU archive library from source code by compiling the C/C++ code with the Position Independent Code option of the gcc compiler.
PIC Executable	This creates an executable from source code by compiling the C code with the Position Independent Code option of the gcc program.
PIC Oracle Executable	This creates an executable from source code by compiling the C code with the Position Independent Code option for gcc and linking to Oracle libraries using gcc.

Compile Plugins to Support Complex Microsoft Builds

Meister supports complex .Net and Windows compiles with extended Microsoft compile plugins. The following Plugins can be purchased to extend your library of reusable Windows Build Tasks.

Name	Description
.NET 2005 Dynamic Link Library	Serialization Creates a Serialize .NET DLL using sgen utility
.NET 2005 Solution Dynamic Link Library	Creates a .NET DLL using a .NET Solution file as a dependency. The DLL can be VB, C#, or C++. Built against the .NET 2.0 Framework
.NET 2005 Solution Executable	Creates a .NET EXE using a .NET Solution file as a dependency. The EXE can be VB, C#, or C++. Built against the .NET 2.0 Framework
.NET C-Sharp Dynamic Link Library	Creates a DLL using the Microsoft .NET C# compiler. The dependency should be the .NET Project file (.csproj). Must run bldmake with -s to preserve case sensitivity
.NET C-Sharp Executable	Creates a command line executable using the Microsoft .NET C# compiler. The dependency should be the .NET Project file (.csproj). Must run bldmake with -s to preserve case sensitivity.
.NET C-Sharp Module	Creates a C# Module using the Microsoft .NET C# compiler. The dependency should be the .NET Project file (.csproj).
.NET ISAPI Extended Dll Shared	Creates a Microsoft .NET Internet Server Extension (ISAPI) or Filter DLL by using the Microsoft .NET C/C++ Compiler. Does not link the Microsoft .NET runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET ISAPI Extended Dll Static	Creates a Microsoft .NET Internet Server Extension (ISAPI) or Filter DLL by using the Microsoft .NET C/C++ Compiler. Links the Microsoft .NET runtime libraries into the executable. Does not require that the runtime libraries be distributed. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET Managed CPP Class Library	Creates a Microsoft .NET DLL using Microsoft .NET C/C++ compiler. The C/C++ code is .NET managed code. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC ActiveX Control Shared Creates	ActiveX control by using the Microsoft .NET C/C++ Compiler. Does not link the Microsoft .NET runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC ActiveX Control Static	Creates a ActiveX control by using the Microsoft .NET C/C++ Compiler. Links the Microsoft .NET runtime libraries into the executables. Does not require that the Microsoft .NET runtime libraries be distributed. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC Dll Shared	Creates a Microsoft .NET DLL with extended features by using the Microsoft .NET C/C++ compiler. An extension DLL allows you to derive custom classes from MFC and lend this "extended" version of MFC to applications that call your DLL. Extension DLLs can be used for passing MFC-derived objects between the application and the DLL. Does not link the Microsoft .NET runtime libraries into the DLL. The runtime libraries must be distributed and loaded dynamically. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC Dll Static	Creates a standard Microsoft .NET executable by using the Microsoft .NET C/C++ Compiler and the Microsoft Foundation Class Libraries. Links the Microsoft .NET runtime libraries into the DLL. Does not require that the Microsoft runtime libraries be distributed. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC Exe Shared	Creates a standard Microsoft .NET executable by using the Microsoft .NET C/C++ Compiler and the Microsoft Foundation Class Libraries. Does not link the Microsoft .NET runtime libraries into the executables. The runtime libraries must be loaded dynamically. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET MFC Exe Static	Creates a standard Microsoft .NET executable by using the Microsoft .NET C/C++ Compiler and the Microsoft Foundation Class Libraries. Links the Microsoft .NET runtime libraries into the EXE. Does not require that the Microsoft runtime libraries be distributed. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET Solution Installer	Creates a MSI file using a .NET Solution file as a dependency.
.NET Visual Basic Dll	Creates a standard Visual Basic .NET dynamic link library. The dependency should be the .NET Project file (.vbproj). Must run bldmake with -s to preserve case sensitivity.
.NET Visual Basic Exe	Creates a standard Visual Basic executable. The dependency should be the .NET Project file (.vbproj). Must run bldmake with -s to preserve case sensitivity.
.NET Win32 Console Shared	Creates a command line program using the Microsoft .NET C/C++ compiler. Does not link the Microsoft .NET runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
.NET Win32 Console Static	Creates a command line program using the Microsoft .NET C/C++ comiler. Links the Microsoft .NET runtime libraries into the executable. Does not require that the runtime libraries be distributed. The dependency should be the .NET Project file (.vcproj .vcxproj). Must run bldmake with -s to preserve case sensitivity.
MFC AppWizard Dll Shared	Creates a standard Microsoft DL by using the Microsoft Foundation Class Libraries.Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MFC AppWizard Dll Static	Creates a standard Microsoft DLL by using the Microsoft Foundation Class Libraries. Links the Microsoft runtime libraries into the DLL. Does not require the Microsoft runtime libraries be distributed
MFC AppWizard Exe Shared	Creates a standard Microsoft executable by using the Microsoft Foundation Class Libraries. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be loaded dynamically.
MFC AppWizard Exe Static	Creates a standard Microsoft executable by using the Microsoft Foundation Class Libraries. Links the Microsoft runtime libraries into the EXE. Does not require that the Microsoft runtime libraries be distributed.
MFC AppWizard Extended Dll Shared	Creates a Microsoft DLL with extended features. An extension DLL allows you to derive custom classes from MFC and lend this "extended" version of MFC to applications that call your DLL. Extension DLLs can be used for passing MFC-derived objects between the application and the DLL. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically
MFC AppWizard Ocx Shared	Creates a Microsoft ActiveX module. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MFC AppWizard Ocx Static	Create a Microsoft ActiveX module. Links the Microsoft runtime libraries into the executable. Does not require that the runtime libraries be distributed.
MSVC Application Shared	Creates a standard Microsoft Executable. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC Application Shared NoPCH	Creates a standard Microsoft Executable. Does not use precompiled header files. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC Application Static	Creates a standard Microsoft Executable. Links the Microsoft runtime libraries into the executable. Does not require that the runtime libraries be distributed.
MSVC ATL COM AppWizard Dll	Creates a Microsoft ATL COM interface DLL. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC COM Dll Shared	Creates a Microsoft COM interface DLL. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC COM Dll Static	Creates a Microsoft COM Interface DLL. Does not require that the runtime libraries be distributed.
MSVC Console Static	MSVC Console Static Creates a command line executable. Links the Microsoft runtime libraries into the executable. Does not require that the runtime libraries be distributed.
MSVC Dynamic Link Lib Shared	Creates a standard Microsoft DLL. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC Dynamic Link Lib Shared NoPCH	Creates a standard Microsoft DLL. Does not use precompiled header files. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically.
MSVC Dynamic Link Lib Static	Creates a standard Microsoft DLL. Links the Microsoft runtime libraries into the executable. Does not require that the runtime libraries be distributed.
MSVC Static Library	Creates a Library that contains object files.
MSVC Threaded Console Shared	Creates a command line program that uses threads. Does not link the Microsoft runtime libraries into the executables. The runtime libraries must be distributed and loaded dynamically
TypeLib	Creates a type library that is used to update the Windows Registry.
VisualBasic	Creates a standard Visual Basic executable. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
Visual Basic 7 Dll	Creates a standard Visual Basic 7 dynamic link library. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
Visual Basic 7 Exe	Creates a standard Visual Basic 7 executable. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
VisualBasic DLL	Creates a standard Visual Basic dynamic link library. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
VisualBasic OCX	Creates a Visual Basic OCX control. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
Visual Basic VBC Console Exe	Compiles Visual Basic with the .NET Framework SDK compiler vbc.exe. It is used for target type 'exe'. It requires that files be listed as dependencies in the target definition file. To compile Visual Basic using a .vbp, .vbproj or a .sln file as a dependency, use the other Visual Basic Plugins.
Visual Basic VBC Library	Compiles Visual Basic with the .NET Framework SDK compiler vbc.exe. It is used for target type 'winexe'. It requires that files be listed as dependencies in the target definition file. To compile Visual Basic using a .vbp, .vbproj or a .sln file as a dependency, use the other Visual Basic Plugins.
Visual Basic VBC Module	Compiles Visual Basic with the .NET Framework SDK compiler vbc.exe. It is used for target type 'winexe'. It requires that files be listed as dependencies in the target definition file. To compile Visual Basic using a .vbp, .vbproj or a .sln file as a dependency, use the other Visual Basic Plugins.
Visual Basic VBC Windows Exe	Compiles Visual Basic with the .NET Framework SDK compiler vbc.exe. It is used for target type 'winexe'. It requires that files be listed as dependencies in the target definition file. To compile Visual Basic using a .vbp, .vbproj or a .sln file as a dependency, use the other Visual Basic Plugins.
VisualBasic VBG	Creates a standard Visual Basic executable. Note: When using the OM -a flag, which forces the rebuild of a VisualBasic executable, the VisualBasic project must allow Binary Compatible compiles. Otherwise a Binary Compatible error will occur.
VS Devenv 2005 Solution Dynamic Link Library	Creates a .NET DLL using a .NET Solution file as a dependency. The DLL can be VB, C#, or C++. Built against the .NET 2.0 Framework
VS Devenv 2005 Solution Executable	Creates a .NET EXE using a .NET Solution file as a dependency. The EXE can be VB, C#, or C++. Built against the .NET 2.0 Framework
VS Devenv 2005 Solution Installer	Creates a MSI file using a .NET Solution file as a dependency.
Borland BCC32 Dynamic Link Library	Uses ilink32 linker to combine object modules (.OBJ files), library modules (.LIB files), and resources to produce executables (.EXE, .DLL, and .BPL files).
Borland BCC32 Executable	Creates a standard executable by using bcc32 to compile and link C and C++ programs. bcc32 defaults to calling ilink32 and processing the link automatically.
Borland Delphi Console Executable	Creates a command line executable using the Borland Delphi Compiler. Only the Delphi Project File (.dpr) needs to be listed as a dependency.
Borland Delphi Console Executable	Creates a command line executable using the Borland Delphi Compiler. Only the Delphi Project File (.dpr) needs to be listed as a dependency.
Borland Delphi DLL	Creates a Dynamic Link Library (DLL) using the Borland Delphi Compiler. Only the Delphi Project File (.dpr) needs to be listed as a dependency.
Borland Delphi GUI Executable	Creates a Windows GUI executable using the Borland Delphi Compiler. Only the Delphi Project File (.dpr) needs to be listed as a dependency.
Borland Delphi Package	Creates a Borland .bpk.
Microfocus Cobol Executable	Creates a standard executable using the Microfocus COBOL compiler.
Microfocus NetExpress Cbllink	Invokes the cbllink Compiler that compiles and links source .cbl cobol files.
Microfocus NetExpress Cbllink	Invokes the cbllink Compiler that compiles and links source .cbl cobol files.
Microfocus NetExpress Compile	Calls the cobol, cblnames and link executables to generate final target dll's and exe's. All dependencies are chained together so that the ouput of one step will automatically be included in the next, with the exception of the cblnames ouput file "cblds.obj." As a result, "cblds.obj" needs to be added as an explicit dependency to the Link task.
Microfocus NetExpress	Creates a Graphical Executable
Microfocus NetExpress	Creates a Graphical SQL Executable
AcuCobol 32 Executable	Creates a standard executable using the AcuCOBOL CCBL or CCBL32 compiler.

Compile Plugins for Complex Java Builds

The following Plugins can be purchased to extend your library of reusable Java Build Tasks. These Plugins are used to compile more complex Java artifacts and gives you the added benefit of dependency management and acceleration of the build.

Name	Description
Java Combine ClassPath	Builds a .classpath file. It uses the Set Classpath to resolve all classpath files. The result can then be included in a different build targets.
Java Copy	Copies dependencies to location(s) defined using the "todir=" parameter available in the pre-defined options. Multiple Option Groups may also be defined for groups of dependencies that need to copy to other "todir=" locations. The Target created in the build directory is a .copy text file containing log information.
Java Ear as Jar	The Java Ear as Jar builds a .jar file using the .ear format. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .ear file. Note that there may be no dependencies in the "Set Classpath" and "Ant Javac" Build Tasks if there is no .java source to compile for the .ear-like .jar file. All of the directory structure requirements of a .jar file are built into the Build Service.
Java Ear no Compilation	Builds an .ear file. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .ear file. Note that there may be no dependencies in the "Set Classpath" and "Ant Javac" Build Tasks if there is no .java source to compile for the .ear file. All of the directory structure requirements of a .ear file are built into the Build Service.
Java Jar no Compilation	Builds a .jar file. It uses the Ant Jar Build Tasks to package up all of the dependencies that need to be included in the final target .jar file.
Java Jar Update	Unjars jar dependencies and adds exploded files to target jar file.
Java JNI	Converts a class file into a header file (.h) for the Java to Native interface. The dependency is the .class file.
Java JUnit Test	Used to run JUnit tests. It runs JUnit tests specified in .java files in the Ant JUnit Test task against the classes and jars specified in the Set Classpath task. Each .java test file will create a corresponding output logfile using the formatter specified by the "type=" option. The JUnit Test task also creates as its target a .test logfile containing the output from Ant. By default the JUnit task runs with the options printsummary="withOutAndErr" and formatter type="xml".
Java RMIC Jar	Incorporates a 4-step process to create a .jar file. The "Set Classpath" and "Ant Javac" Build Tasks define the classpath and compile javac files to class files as in other Plugins. The "Ant RMIC" Build Task takes as source the compiled classes from "Ant Javac" and generates other class files. The "Ant RMIC Jar" Build Task jars classes from both the "Ant Javac" and "Ant RMIC" Build Tasks.
Java Signed Jar	Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java Tar	Builds a .tar file. It uses the Ant Tar Build Task to package up all of the dependencies that need to be included in the final target .tar file
Java War as Jar	Builds a .jar file in the format of a .war file. It uses the Set Classpath, Ant Javac and Ant War Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file. All of the directory structure requirements of a .war file are built into the Build Service final .jar file.
Java War no Compilation	Builds a .war file. It uses the Set Classpath, Ant Javac and Ant War Build Tasks to compile and package up all of the dependencies that need to be included in the final target .war file. All of the directory structure requirements of a .war file are built into the Build Service.
Java WBIMB BAR File	Java Weblogic Ant wlappc Compile Prepares the compile by setting the Classpath. The Classpath should include the library containing the APPC compiler, most likely weblogic.jar. Uses Ant APPC Compile Task to compile APPC dependencies with the weblogic.appc compiler.
Java Weblogic APPC Compile	Prepares the compile by setting the Classpath. The Classpath should include the library containing the APPC compiler, most likely weblogic.jar. Uses Ant APPC Compile Task to compile APPC dependencies with the weblogic.appc compiler.
Java Weblogic Clientgen Jar	Uses the Weblogic clientgen task to create a client JAR file that contains a thin Java client used to invoke a Web Service. Takes an EAR file that contains the implementation of a WebLogic Web Service as a depencency.Java Weblogic EJB Compile Prepares the compile by setting the Classpath. The Classpath should include the library containing the EJB compiler, most likely weblogic.jar. Uses Ant EJB Compile Task to compile EJB dependencies with the weblogic.ejbc compiler.
Java Weblogic EJB Compile and Jar	Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.Java Weblogic JSPC Compile Prepares the compile by setting the Classpath. The Classpath should include the library containing the JSP compiler, most likely weblogic.jar. Uses Ant JSP Compile Task to pre-compile JSP dependencies with the weblogic.jspc compiler.
Java Weblogic Servicegen Ear	Servicegen performs all Weblogic steps needed to assemble a Web Service. These steps include: - Creating the Web Service deployment descriptor (web-services.xml). - Introspecting EJBs and Java classes and generating any needed non-built-in data type supporting components. - Generating the client JAR file. - Packaging all the pieces into a deployable EAR file.
Java Weblogic War	Builds a .war file. It uses the Set Classpath, Ant Javac and Ant War Build Tasks to compile and package up all of the dependencies that need to be included in the final target .war file. All of the directory structure requirements of a .war file are built into the Build Service.
Java Weblogic WLI Ear no Compile	Builds an .ear file. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .ear file. Note that there may be no dependencies in the "Set Classpath" and "Ant Javac" Build Tasks if there is no .java source to compile for the .ear file. All of the directory structure requirements of a .ear file are built into the Build Service.
Java Weblogic WLI Jar	.jar Final Results Extension: .jar Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java Weblogic WLI War	Builds a .war file. It uses the Set Classpath, Precompile (xmlbean and apt tasks), Ant Javac and Ant War Build Tasks to compile and package up all of the dependencies that need to be included in the final target .war file. All of the directory structure requirements of a .war file are built into the Build Service.
Java Weblogic XMLBeans Jar	.jar Final Results Extension: .jar Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java WebSphere 5.1 EJBDeploy EAR	Use this build service when developing with IBM WebSphere Studio Application Developer 5.1 to generate deployment code and classes for an EAR. The dependency is the EAR built by the Openmake Eclipse Plugin-generated target files and the output file is the deployable EAR. The WAS_HOME environment variable MUST be set, e.g. WAS_HOME=C:\Progra~1\IBM\WSADv5.1 To build a deployable EAR for the MiniBank example, use the following values in the target definition: Final Target Name: MiniBankEAR.ear Final Target Output Path: deploy Dependency: MiniBankEAR.ear
Java WebSphere 5.1 WSEJBDeploy	Use this build type when developing with IBM Websphere Application Developer 5.1 to generate deployment code and classes.The dependency is the JAR built by the Openmake Eclipse Plugin-generated target files and the output file is the deployable JAR. The WAS_HOME environment variable MUST be set, e.g. WAS_HOME=C:\bin\WebSphere\AppServer
Java WebSphere 6.0 EJBDeploy EAR	Use this build service when developing with IBM Rational Application Developer 6.0 for WebSphere Software to generate deployment code and classes for an EAR. The dependency is the EAR built by the Openmake Eclipse Plugin-generated target files and the output file is the deployable EAR. The WAS_HOME environment variable MUST be set, e.g. WAS_HOME=C:\bin\WebSphere\AppServer To build a deployable EAR for the AutoWorld example, use the following values in the target definition: Final Target Name: autoworld.ear Final Target Output Path: deploy Dependency: AutoWorld20ExampleEAR.ear
Java Websphere Application Client Jar	Builds an .jar file. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java Websphere Ear	Builds an .ear file. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .ear file. Note that there may be no dependencies in the "Set Classpath" and "Ant Javac" Build Tasks if there is no .java source to compile for the .ear file. All of the directory structure requirements of a .ear file are built into the Build Service.
Java WebSphere EJBDeploy Complete	Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java WPS Service Deploy	Builds a .ear file. It uses the Ant Zip Build Tasks to package up all of the dependencies that need to be included in the final target .ear file and use servicedeploy to create the .ear.
Java Zip	Builds a .zip file. It uses the Ant Zip Build Tasks to package up all of the dependencies that need to be included in the final target .zip file.
Manage Ear Deployment Descriptors	Insert and replace XML tags and values in deployment descriptors of an archive. It unjars the files to be updated from the archive, next it will insert and replace the XML tags and values and finally create a new jar with the updated files to the Target name.
Manage War Deployment Descriptors	Insert and replace XML tags and values in deployment descriptors of an archive. It unjars the files to be updated from the archive, next it will insert and replace the XML tags and values and finally create a new jar with the updated files to the Target name.
MD5 Checksum	Creates a Target file with a .md5 extension that contains the MD5 checksum information of the dependent file. The checksum value is also outputted to the build log. This value is useful in determining if a Target built as expected.
Update Deployment Descriptors	Insert and replace XML tags and values in deployment descriptors of an archive. It unjars the files to be updated from the archive, next it will insert and replace the XML tags and values and finally updated the original jar with the updated files.

Blog: OpenMake Software Receives SD Times 100 Award

Mon, 22 Jun 2020 00:00:00 +0000

OpenMake Software Receives SD Times 100 Award OMS recognized by SD Times in the DevOps Leadership category for the fourth consecutive year.

Santa Fe–June 22, 2020– OpenMake Software announced today that they received the SD Times 100 Award for DevOps Leadership for the 4th year in a row. OpenMake Software, the creators of OpenMake Meister for build and release management, democratized continuous deployments with their contribution and support of the Oretlius Open Source Project. The award recognizes leaders and innovators of the software development industry for 2020.

SD Times explains, “When choosing the SD Times 100, we carefully considered each company’s offerings and reputation. We also listened for the “buzz”—how much attention and conversation we’ve heard around the company and its products and technologies—as a sign of leadership within the industry.” Congratulations to all who won awards this year, the full list is available online.

Receiving the award for the forth consecutive year is an important achievement for OpenMake Software as their stated goals is to be ‘disrupters’ in the Application Release Automation space. OpenMake Software, together with DeployHub, will release the latest open source Ortelius 9.0 Version in early July.

“We make configuring software builds and deployments easy,” says Steve Taylor, Chief IT Architect of OpenMake Software. “Access to automated build and deploy tooling is a barrier for development teams due in large part to the cost. We are democratizing continuous deployments for all. And the Ortelius Microservice Management open source project is leveraging our core configuration expertise designed for microservices. "

SD Times launched in February 2000 by BZ Media, and is the newspaper of record for the software development industry. SD Times is published twice monthly in print and at www.sdtimes.com.

DeployHub is a central hub of microservice configuration metadata. It tracks and versions the ‘death star’ thus simplifying the migration to – and ongoing management of – a microservice architecture. They understand the importance of supporting today’s cloud and physical data centers, but maintain a strong focus on the critical need for a microservices and Kubernetes platform.

Blog: SDTimes 100 Award goes to OpenMake Software in DevOps Category

Mon, 10 Jun 2019 00:00:00 +0000

OpenMake Software Receives SD Times 100 Award OMS recognized by SD Times in the DevOps Leadership category

Santa Fe, NM–June 10, 2019– OpenMake Software, the company who started DeployHub for microservice configuration management, today announced receipt of the SD Times 100 Award for excellence and leadership in the DevOps category. The award titled “SD Times 100” recognizes leaders and innovators of the software development industry for 2019 in 11 separate industry segments.

This SD Times 100 award is an important achievement for OpenMake Software as their stated goal is to be a ‘disrupter’ in the DevOps space supporting continuous deployments for both monolithic and microservice releases. To this end, the co-founders created a new company, DeployHub Inc., with a laser focus around microservice tracking, sharing, versioning and deployments - critical pieces of the Kubernetes pipeline. DeployHub is based on the open source project called Ortelius for microservice configuration mapping.

“Companies are building out Kubernetes pipelines that need features to manage microservices”, explained Tracy Ragan, CEO and Co-Founder of OMS and DeployHub. “With DeployHub, we provide a central microservice sharing platform that tracks the configuration of microservices and maps the logical view of a monolithic application. And yes, we can deploy an independent microservice fast and safely with versioning and history.”

About SD Times

Launched in February 2000, BZ Media’s SD Times is the newspaper of record for the software development industry. SD Times is published twice monthly in identical print and digital editions and can also be read online at www.sdtimes.com.

About OpenMake Software®

OpenMake® Software delivers highly reusable DevOps Solutions that allow our customers to master agile’s last mile. For more information on OpenMake Software, go to www.OpenMakeSoftware.com

About DeployHub®

DeployHub is a central microservice sharing platform where developers catalog, publish, version and deploy their applications built on-top of Kubernetes. For more information go to DeployHub.com

Blog: OpenMake Software Spins Off New Company - DeployHub Inc.

Thu, 19 Jul 2018 00:00:00 +0000

OpenMake Software announces the spin-off of a new company, DeployHub, Inc. for the purpose of providing Open Source Application Release Automation for Continuous Deployment

Santa FE, NM – July 19, 2018 – OpenMake® Software, visionaries in continuous build and continuous deployment, today announced that they have formed a new company, DeployHub Inc., that will serve to support the DeployHub Open Source Continuous Deployment project.

“DeployHub, Inc. has been formed by the co-founders of OpenMake Software for the sole purpose of providing freely available, full strength, continuous deployments to high performing agile teams.” said Tracy Ragan, CEO of OpenMake Software. “We recognize that the high cost of Application Release Automation is a barrier to agile teams wanting to adopt full stack continuous deployments. DeployHub Open Source will break that barrier.”

DeployHub, Inc. will support the DeployHub Open Source community and provide an open source SaaS offering for a frictionless road to full continuous deployment. For more information, go to www.deployhub.com.

About DeployHub, Inc.

DeployHub Inc. is driven by the goal to firmly establish continuous deployments as a reality for high performing agile teams, allowing them to rapidly and safely release new innovation to their software end users. We understand the importance of supporting today’s cloud and physical data centers, but maintain a strong focus on the future needs of the new microservices and Kubernetes environments. More at DeployHub.com

About OpenMake Software

OpenMake Software is a registered trademark of Catalyst Systems Corporation. All other trademarks used in this document are the property of their respective owners.

DeployHub is a registered trademark of DeployHub Inc. All other trademarks used in this document are the property of their respective owners.

DeployHub,Inc., 2232 Dell Range Blvd Suite 245-3467, Cheyenne, WY 82009 Mailing: P.O. Box 659, Cerrillos, NM 87010

Twitter: @DeployHubProj

Facebook: /DeployHub

GitHub: https://groups.google.com/forum/#!forum/deployhub-project

Blog: OpenMake's CEO Recognized as WIT Honoree by NM Technology Counsil

Wed, 07 Mar 2018 00:00:00 +0000

New Mexico Technology Council Recognizes Tracy Ragan for Her Career in Software Development

Santa FE, NM – March 7, 2018 – OpenMake® Software, visionaries in continuous build and continuous deployment, today announced that Tracy Ragan, OpenMake Software, CEO has been recognized as a New Mexico Women In Technology (WIT) Honoree by the New Mexico Technology Council.

“I’ve worked in what is now called Continuous Delivery since 1995. It is a pleasure to be recognized for my contribution in this particular technology by the New Mexico Technology Council” said Tracy Ragan, CEO of OpenMake Software. “Being part of a group of women is particularly important when the end game is to bring more young woman into STEM.”

“Tracy is among an amazing group of honorees this year. We are pleased to see more technology moving into New Mexico and particularly happy to see technology firms with women at the helm,” said Nadine Buerger, Investor and Program Manager for NM Technology Counsil, organizers of the NM WIT Annual Event.

About New Mexico Technology Council The New Mexico Technology council is focused on creating opportunities for tech based business in New Mexico supporting a forum for member companies to connect & grow. The board is made up of individuals from a wide range of backgrounds with a common goal of economic development in STEM.

About OpenMake Software OpenMake® Software delivers highly reusable DevOps Solutions that allow our customers to master agile’s last mile. As a 100% self-funded organization, we have the freedom to focus on our customer’s needs, delivering innovation in continuous builds and continuous deployment.

Blog: OpenMake® Software Joins Cloud Native Computing Foundation

Thu, 18 Jan 2018 00:00:00 +0000

OpenMake Software focuses on Kubernetes® and Cloud Native Computing

Santa FE, NM – January 18, 2018– OpenMake® Software, visionaries in continuous build and continuous deployment, today announced they have joined the Cloud Native Computing® (CNCF®) – which sustains and integrates open source technologies like Kubernetes® and Prometheus™ – as a Silver member.

“Innovation in Continuous Deployment as it relates to Kubernetes, microservices and the server-less data center will be critical for our customers.” said Tracy Ragan, CEO of OpenMake Software. “Being part of the CNCF will help us drive innovation in this area, allowing DeployHub to solve both the software release challenges of today, and be aligned with the community addressing challenges created by this new wave of digital transformation.”

“We’re thrilled to welcome OpenMake Software as a new member,” said Dan Kohn, Executive Director of the Cloud Native Computing Foundation. “The company’s experience in continuous build and delivery makes them a great addition to the CNCF community.”

About Cloud Native Computing Foundation

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization. The Cloud Native Computing Foundation (CNCF) hosts critical components of cloud native software stacks, including Kubernetes and Prometheus. CNCF serves as the neutral home for collaboration and brings together the industry’s top developers, end users and vendors – including the world’s largest public cloud and enterprise software companies as well as dozens of innovative startups. CNCF is part of The Linux Foundation, a nonprofit organization. For more information about CNCF, please visit www.cncf.io.

About OpenMake Software

OpenMake® Software delivers highly reusable DevOps Solutions that allow our customers to master agile’s last mile. As a 100% self-funded organization, we have the freedom to focus on our customer’s needs, delivering innovation in continuous builds and continuous deployment. An investment in our DevOps solutions or Professional Services forms a ‘technical partnership’ that provides you expertise and support to solve your toughest build and release problems for today and tomorrow.

More Info at www.OpenMakeSoftware.com

OpenMake Software is a registered trademark of Catalyst Systems Corporation. All other trademarks used in this document are the property of their respective owners.

Blog: Common Meister Compiler Plugins

Fri, 30 Jun 2017 00:00:00 +0000

Common Compile Plugins - covers most of Your Compile Needs

Meister standardizes your software compiles using compiler plugins. The following plugins are included with Meister. If you are needing more complex plugins, such as database management or mobile development, check out our advanced plugins.

C/C++ Compiler Plugins

Name	Description
CPP Executable	Creates a standard executable by using xlC_r to compile and link C and C++ programs
CPP Shared Library	Specific to C++ and the use of mangled class names. Creates a standard C++ shared library by using xlC_r to compile C and C++ programs. Uses makeC++SharedLib for Linking.
Entry Shared Library	This shared library contains an entry point option for cc in the Link Build Task. The shared library is created by using the ar command to create the final object
Entry Shared Object	This shared library contains an entry point option for cc in the Link Build Task. The shared object is not formatted by ar.
AIX Executable	Creates an executable target from .c code using the default c compiler. It has two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and libraries to create the Final Target executable.
Yacc C File	Used to generate a C source file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.
Yacc C Header File	Used to generate a C source header file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.

Java Compile Plugins

Name	Description
Ant Java Doc	Used to create documentation using the Ant Javadoc task. It generates an index.hml file. This file's timestamp is compared against Java and Classpath dependencies' timestamps in incremental builds. Because a standard file name "index.hml" is used for all JavaDoc Targets, it is recommended that each Javadoc Target be created in a separate directory, e.g. javadoc1/index.html, javadoc2/index.html, etc.
Java Set Classpath	.classpath Builds a .classpath file. It uses the Set Classpath to resolve all classpath files. The result can then be included in a different TGT.
Java Jar	Builds a .jar file. It uses the Set Classpath, Ant Javac and Ant Jar Build Tasks to compile and package up all of the dependencies that need to be included in the final target .jar file.
Java War	Builds a .war file. It uses the Set Classpath, Ant Javac and Ant War Build Tasks to compile and package up all of the dependencies that need to be included in the final target .war file. All of the directory structure requirements of a .war file are built into the Build Service.
Java Ear	Builds an .ear file. It uses the Set Classpath, Ant Javac and Ant Ear Build Tasks to compile and package up all of the dependencies that need to be included in the final target .ear file. Note that there may be no dependencies in the "Set Classpath" and "Ant Javac" Build Tasks if there is no .java source to compile for the .ear file. All of the directory structure requirements of a .ear file are built into the Build Service.
Java Javadoc	Used to create documentation using the javadoc program. It generates an index.hml file. This file's timestamp is compared against Java and Classpath dependencies' timestamps in incremental builds. Because a standard file name "index.hml" is used for all JavaDoc Targets, it is recommended that each Javadoc Target be created in a separate directory, e.g. javadoc1/index.html, javadoc2/index.html, etc.Because of the wide variation in the use of the Javadoc command, customization of the JDK Javadoc Task may be required. There will be no need to modify the Java Javadoc Build Service The Target Name should be index.html or <subdirectory>/index.html. Typical Tasks would be 1. Set Classpath, 2. JavaDoc.
Java Javadoc Jar	Used to create documentation using the javadoc program. Generates an index.hml file. This file's timestamp is compared against Java and Classpath dependencies' timestamps in incremental builds. Because a standard file name "index.hml" is used for all JavaDoc Targets, it is recommended that each Javadoc Target be created in a separate directory, e.g. javadoc1/index.html, javadoc2/index.html, etc.Because of the wide variation in the use of the Javadoc command, customization of the JDK Javadoc Task may be required. There will be no need to modify the Java Javadoc Build Service The Target Name should be index.html or <subdirectory>/index.html. Typical Tasks would be 1. Set Classpath, 2. JavaDoc.
Java Compile	Uses the Ant "javac" task to compile Java code files. All dependencies added to this Build Task will be compiled using the compiler specified in the "compiler" Option parameter.

Microsoft Compiler Plugins

Name	Description
MSBuild Dynamic Link Library	Creates a .NET EXE using a .NET Solution file as a dependency. The EXE can be VB, C#, or C++. Built against the .NET 2.0 Framework
MSBuild Executable	Creates a .NET EXE using a .NET Solution file as a dependency. The EXE can be VB, C#, or C++. Built against the .NET 2.0 Framework
MSBuild Website	Creates a final results extension: .webproject
.NET Solution Dynamic Link Library	Creates a .NET DLL using a .NET Solution file as a dependency. The DLL can be VB, C#, or C++.
.NET Solution Executable	Creates a .NET EXE using a .NET Solution file as a dependency. The EXE can be VB, C#, or C++.
Yacc C	Used to generate a C source header file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.
Yacc C Header File	Used to generate a C source header file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.
Gnu Exe	Creates a standard executable. It uses gcc to compile and link C and C++ programs.
Gnu DLL	Creates a standard DLL. It uses the gcc to compile and link C and C++ programs.
Wise Installer	Uses Wise Installer to create the disk images for the installer. The dependencies are .wsi, .dll and.exe files.
InstallShield	Uses Installshield to create the disk images for the Installer. The dependencies are the setup.rul, .ipr, .dll and .exe files.
Perl Script	Will execute a set of Perl scripts listed as dependencies in the Target file. The order that the scripts will be executed is random. If a particular order is required, a "driver" Perl script should be used as the single dependency in the Target that includes the list of Perl script to execute in the correct execution order.

UNIX/Linux Plugins

Name	Description
CPP Executable	Creates a standard executable by using xlC_r to compile and link C and C++ programs
CPP Shared Library	Specific to C++ and the use of mangled class names. Creates a standard C++ shared library by using xlC_r to compile C and C++ programs. Uses makeC++SharedLib for Linking.
Entry Shared Library	This shared library contains an entry point option for cc in the Link Build Task. The shared library is created by using the ar command to create the final object
Entry Shared Object	This shared library contains an entry point option for cc in the Link Build Task. The shared object is not formatted by ar.
AIX Executable	Creates an executable target from .c code using the default c compiler. It has two tasks; Compile and Link. The Compile Build Task converts source code to .o object files. The Link Task links .o object files and libraries to create the Final Target executable.
Yacc C File	Used to generate a C source file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.
Yacc C Header File	Used to generate a C source header file from a yacc source file when the C file needs to have a different name from the yacc file. There is also a Build Task under available tasks with the same rule that can be imported into any build service that compiles C code.

Blog: OpenMake Meister Provides Cross Platform Benefits for z/OS Developers

Fri, 30 Jun 2017 00:00:00 +0000

OpenMake Meister Supports z/OS Compiles for Cross Platform Builds.

OpenMake Meister for z/OS is the only build automation solution available that allows you to build and manage binaries, across the enterprise - from Windows and Unix to the mainframe, providing a cross platform build solution. Meister for z/OS provides a central, common build management method for managing your binaries, regardless of the language or Operating System.

So go ahead, develop on the mainframe. We have you covered.

Key Benefits:

Build Management Best Practices

Meister for z/OS Build Services enable build management best practices by defining standard procedures for calling z/OS compilers. Build Services are based on REXX and can be developed using the Meister for z/OS rich library of reusable REXX modules that perform common tasks such as generating JCL. Meister enable build best practices and enforces standard procedures in every build you execute.

Adaptable and Dynamic Builds

OpenMake Meister for z/OS is the perfect solution for developers writing applications that connect diverse platforms. When your application spans both the legacy mainframe environment as well as the distributed environment, you need a method for building the application as if it runs on a single platform. Meister standardizes and centralizes the creation of binaries for both the mainframe and distributed platforms.

On-demand Build Knowledge

Meister for z/OS integrates into the Meister community-developed knowledge base, enabling cross-platform build coordination. The community-developed knowledge base keeps all developers in sync providing a shared build object repository, common locations for reporting on parameter usage, and environment variable usage. Build logs, reports and schedules are centralized, providing the self-service and self-documented build management support needed in today’s lean development environments.

Managing Source to Load Parity

Meister for z/OS provides the deep dependency discovery needed for exposing the artifacts used to create your load objects. Even when components are not stored in a version control tool, Meister for z/OS will provide the precise location of all source, objects and libraries, and where they were found when creating the binary. When an application failure occurs, you need to trace the source of the offending event, similar to using fingerprints and DNA to track down the suspect of a crime. With Meister for z/OS’s advanced dependency discovery and reporting, every item used to create the binary is stored in an application “footprint” and reported in the application “Build Audit Report” regardless of versioning tool usage.

Blog: Why Use Meister Build Automation with Continuous Integration

Fri, 30 Jun 2017 00:00:00 +0000

Build Automation for Agile Teams with Complex Builds

Meister Build Automation accelerates Continuous Integration to improve the management, control and speed of the software compile and link process. Meister and scale to large compile requirements supporting over 20,000 builds per day. Meister build automation improves your agile development by matching the adaptive and iterative nature of your source code changes with the quick compilation of your binaries. Meister Build Automation eliminates build bottlenecks caused by slow compiles, manual updates to scripts and errors common to a build process that is driven by static processes. It provides:

Build (compile/link) acceleration;
Commercial strength server pooling and load balancing;
Hundreds of compiler plugins for easy implementation;
Reproducible builds - inside and outside the IDE;
Dependency management;
Microsoft .Net Multiple Solution File Dependency Management;
Build audits;
Build script generation;
Custom playbooks to standardize and manage how compilers are called;
Managed declared inputs using ‘VPATH’;
Out of the box, Meister supports over 200 compile Plugins.

Accelerated Builds for Continuous Integration

Meister Build Automation has the intelligence to drastically reduce your build times for full builds and down to a few seconds with accurate incremental builds. Meister uses Build Avoidance only re-building the source code that has been changed. So easy! Meister supports build acceleration for all supported languages including Java, .Net, C++, C-Unix and others including the ability to manage multiple .Net Solution files in a single parallel build stream.

View the Build Automation Demo

Build Automation Insight

When a build is executed in ‘audit’ mode, Meister Build Automation grabs the version control item history, showing in the audit report the artifact version information, which can be used to trace a change in a build back to a particular developer. Meister’s Build Insight exposes the source code and dependencies used to create your binaries giving you insight into the readiness of your software release even when the source is not stored in a version control tool.

Jenkins Continuous Integration at Scale

OpenMake Meister’s Server Pool management features include the ability to automatically select the most efficient machine in the pool for the fastest processing possible. You can use Meister’s in conjunction with Jenkins to scale your Continuous Integration across large build environment. And you can add Build Servers and Pools for load balancing as you need them keeping your cost low and managed.

Automatic Dependency Management and Impact Analysis

Meister uses deep dependency scanning to make build decisions and to report on the impact of a potential software change. By running a Build with Impact Analysis enabled, a detailed report will be generated and can be shown ’exploded’ going from source to binary or ‘imploded’ from binary to source. Meister’s Dependency Management is used at multiple levels. It is used to accelerate builds with both Build Avoidance and building in parallel, and is used to audit the build, showing all artifacts used even when they are not stored in version control.

Playbooks and Plugins

Meister uses playbooks and plugins, to create consistent build logic. After implementing Meister, a large Financial Service went from several hundred build scripts to less than a dozen playbooks. If an update needs to be made to one of the playbooks, it is done in a single location and shared by all. Meister was the first to use plugin and playbooks for standardizing compiles but not the last.

So, start accelerating your Builds today. What are you waiting for?

Download the Free version of Meister at GitHub.

Blog: Incremental Builds are Critical for Continuous Builds

Thu, 29 Jun 2017 00:00:00 +0000

Incremental Builds are Critical for Fast Continuous Builds.

Incremental builds are important for managing continuous builds for continuous delivery. Handing over a release from dev to prod must be easy and automated. The production side of the house cannot always be expert in every team’s application, there can be just too many in large organizations. So one way to keep it simple is to perform incremental deploys when at all possible. The key to incremental deploys is an incremental build. One hand feeds the other. In the Make world, or more specially ClearMake, this was called Build Avoidance. It seems that the art of avoiding building objects has all been lost even though it is critical to agile developers and the DevOps process.Incremental Builds are critical for fast continuous build and breaking down waterfall barriers and adopting agile practices.]

Break Down Waterfall Barriers with Incremental Builds

The Build itself must become incremental to fully support a development process where incremental changes are encouraged. If not, your Continuous Integration process is impeded by a slow Build process written to support a waterfall methodology. Hence, a slow compile creating all binaries each time – the “big bang” approach. When using OpenMake Meister for powering Build, the default Build is an incremental Build. Nothing special is required to execute a build using Build Avoidance. Your Build will automatically be executed on an incremental basis. Therefore, you are reducing your Build times down from hours to minutes.

Reduced Build Times for Continuous Build

Incremental Builds substantially decrease Build times by avoiding the execution of Build steps that are not needed. This is a critical component of lean methodologies such as Agile Unified Process (Agile UP), Scrum, and Rhythm (Unified Build Infrastructure). So, If you are looking for ways to improve Build times, the use of incremental Build will allow you to reach your goal.

Incremental Builds determine all dependent relationships in the Build regardless of language. For Java, an incremental Build determines the dependency of all .jar, .war and .ear files. This also includes jar files that are used by other jar files and their dependent java source files. Similarly, in more traditional languages such as C/C++ or COBOL, dependency relationships are discovered for all included headers, copybooks, etc.

Note: If you are using Meister and choose to always execute Builds using a “clean all” approach, pass the following parameters to the om process when executing your Builds:

-a or clean all

If the clean all parameter is not passed, your Build will be performed in the most efficient manner using Build Avoidance.

Blog: Build Avoidance and Continuous Integration: Accelerating the Compile Process

Tue, 27 Jun 2017 00:00:00 +0000

Build Avoidance - Work Smarter not Harder.

Build Avoidance is a build term that refers to the process of accelerating the compile process by not rebuilding objects that are up to date. This can improve your compile/link times substantially. Build Avoidance should be a primary function of your compile solution.

In my opinion, Build Avoidance should be a primary function of your compile solution. When used, it greatly improves the speed of your incremental builds. It is not “new” by any means. Build Avoidance was a term coined by IBM. It referred to the way ClearMake managed compiled objects. It worked then, and still works now.

Cross Platform Build Avoidance

For most build solutions, the biggest challenge is to support build avoidance for all languages from Unix C to .Net and Java. For example, the “gnumake” based scripting languages only supports C/C++ languages. Maven scripting supports “pseudo incremental builds” which really is the opposite of what you would think. Maven’s “pseudo incremental builds” does a “clean all” on the Projects that have changed, not on just the source code that has changed. Doing a “clean all” is not avoiding a build, it is making sure that objects will be rebuilt by deleting them.

Meister has supported Build Avoidance for all languages for over 20 years. Only OpenMake Meister can actually make the claim for C/C++, .Net, Java and yes, even COBOL.

Beware of False Prophets

So the moral of the story is, if your build automation tool is not supporting Build Avoidance you should look for a better build solution. Build avoidance is the process of executing a build with full knowledge of the dependencies. In addition, it understands which dependencies are out of date and need to be re-built. This is a core function of build automation. The best way to speed up a build is to not recreate objects that are already available.

Critical to Continuous Integration: Compile and Link Process Must Work Smart

As long as we are on the topic of Build Avoidance, let’s bring up how critically important it is to your Continuous Integration process. Remember - your Continuous Integration process is only as good as your build scripts. To improve your CI process the engine that drives your compile and link process must work “smart.” What does “smart” mean you ask. A smart build knows more than you do about how your application is put together. This means that is understands the dependencies (compile, provided, system scope, etc). With those dependencies is can accurately rebuild your application by only updating what has been changed.

Yes, you can do this for Java, .Net or any native language such as C/C++. What does this buy you. First, in most cases your CI compile and link step will execute in less than a few minutes. Secondly, you are given a platform for doing pre-flight builds where any developer can re-compile the entire application, locally, without wasting an hour (or a few hours).

If you want your CI process to run really fast and accurately, make your builds “smart” so you don’t have to run “clean all” every time you execute a pre-flight or CI build. Hey it is 2017 already. Start using your computer to orchestrate your compile and link process and stop writing static scripts that lack the ability to support your development process without your constant attention. This is real build automation.

Blog: OpenMake Receives SDTimes 100 Award

Wed, 07 Jun 2017 00:00:00 +0000

OpenMake Software recognized by SD Times in the DevOps Leadership category.

Las Vegas, NV–June 7 2017– OpenMake Software, visionaries in continuous build and continuous deployment, today announced receipt of the SDTimes 100 Award. OpenMake received the award for excellence and leadership in the DevOps category. The award titled “SDTimes 100” recognizes leaders and innovators of the software development industry for 2017 in 11 separate industry segments.!

“The software development industry is led by innovative companies like OpenMake Software,” David Rubinstein, editor-in-chief of SDTimes, said. “When choosing the 2017 SDTimes 100, we carefully considered each organization’s products and services, reputation with software development managers, and the new ideas and thought leadership that it brings to the industry. Thanks to companies like OpenMake, the art and science of software development continues to advance at a rapid pace.”

This SDTimes 100 award is an important achievement for OpenMake Software. It recognizes OpenMake’s stated goal to be a ‘disrupter’ in the Application Release Automation space. In March they began offering an DeployHub, a fully functional ARA solution designed for agile teams pursuing Continuous Deployment. “Our goal is to help organizations master agile’s last mile- which is the point where production deployments keep up with the pace of agile” explained Tracy Ragan, CEO and Co-Founder. “We appreciate that SDTimes has recognized the impact we are making on the agile DevOps space, particularly in maturing continuous delivery to support the full pipeline from development through production.

About SD Times

Launched in February 2000, BZ Media’s SDTimes is the newspaper of record for the software development industry. SDTimes is published twice monthly in identical print and digital editions and can also be read online at www.sdtimes.com.

About OpenMake Software

For more information on OpenMake Software, go to www.OpenMakeSoftware.com

Blog: No Meister Conversion required

Fri, 26 May 2017 00:00:00 +0000

No Meister Conversion Required to Start Using Meister Build services.

Meister conversion is a myth. To use Meister, our competitors would like you to believe that an Ant to Meister or Maven to Meister conversion is required. We are often asked, “how long does it take to convert my Ant Scripts to Meister?” The answer is there is really no requirement to “convert” to Meister. Meister will do that for you by referencing the most accurate information found - the Eclipse or Microsoft .Net Project files.

Ant and Maven Extras

Ant Scripts can do many steps including calling version control and executing a deployment. If these kinds of steps are in your Ant scripts, you will need a Meister conversion to your CI workflow. Meister includes calls to common activities that are included in CI Workflows. For example, calling version control tools, static testing and automated configuration management. You will end up creating a CI workflow that performs the same steps as your existing Ant Scripts.

Meister Generates a New Script

Instead of a Meister conversion, Meister will use your Eclipse Project files to generate the “ant” like process for creating your jars, wars, ears. An Ant to Meister conversion is a misunderstanding of how Meister is configured. Meister uses Targets instead of a script of any type. Instead of manually creating Targets, you can automatically generate them using your development IDE. If you are currently executing builds using scripts, and you use an IDE, you let Meister generate what you need. Meister can automatically generate your Targets based on the IDE Project file using the Eclipse plug-in. This is the preferred method. Your IDE Project file is the most accurate reflections of how your Java component is built. Therefore automatically generating the Target based on the Project file will provide the most accurate results.

In addition, by automatically generating your Java Targets via your IDE, you can improve your Continuous Integration process. By auto generating your Targets you can synchronize the builds performed inside of the Eclipse IDE with the builds running outside of the Eclipse IDE. This synchronization resolves changes made to the source code that has impacted the build scripts running outside of the IDE such as the case with refactoring, adding libraries, or changing compile options.

The Meister TGT Plug-in

The Meister TGT Generation Plug-In integrates with Eclipse, IBM Rational Application Developer, IBM Rational Software Architect, MyEclipse, Weblogic Workshop, IBM WebSphere Studio Application Developer, and CodeGear.

When using the Target Generator, Targets are automatically generated and maintained by the Plug-In. The Plug-In can be configured to automatically create and update .tgt’s when:

A file is added or removed from a referenced Eclipse project

Referenced Eclipse project properties such as Java Build Path are updated

Developers choosing to use the Eclipse plug-in should first setup the configuration of the Eclipse Target Generator. Once your configuration has been setup you can then define a Project and Dependency Directory and configure their Eclipse projects to use the Target generation and build features. Note: To validate that you have the Eclipse Target Generator already installed simply view the list of plug-ins available from the Eclipse IDE. If the Meister Eclipse Target Generator is installed you will see “OpenMake TGT Generator” in the list.

Blog: Distributed builds and Configuring Remote Agents

Sun, 07 May 2017 00:00:00 +0000

Using Distributed Builds with Remote Agents for Continuous Integration.

Distributed builds requires the use of Remote Agents. A common question I see on our support forums is how to configure Remote Agents to maximize machine resources.

Configuring Remote Build Agents

When using Meister you can configure a variety of Remote Agents types including:

Physical
Pre-Provisioned Virtual
Amazon EC2, HyperV, and vCenter

You can configure Remote Agents for load balancing, process utilization and distribution by setting the following parameters.

CPU % Threshold

Used to create a weighted value for use in deciding to which machine a queued activity will be assigned during load balancing. Recommend value is 80%. For instance, if there are two Remote Agents, Agent A and Agent B, a CPU % Threshold can be assigned to determine which machine to use first.

The equation for this weighted value is:

CPU % Threshold – Current CPU % Usage

For example, if Agent A and Agent B both have a CPU % Threshold of 80%, and Agent A is currently running at 50% CPU, its weighted value will be 30. If Agent B is running at 70% CPU utilization, its weighted value will be 10. In this case, if all other settings for the two Remote Agents are the same, Agent A will have the queued activities assigned to it, since it has a higher differential between CPU % threshold and current CPU % usage.

Queue Depth Threshold

Determines how many Workflow Activities will be queued up to run before the KB server starts offloading activities to other Remote Agents in the Server Pool. The value of this number is determined by the amount of resources available to process Workflow Activities. You can enter a number between 1 and 200. The initial recommended value to 10 and can be increased if additional Remote Agents are being started unnecessarily. The higher the number, the larger the queue.

Max # of Running Workflows

Controls how many Workflows can be run simultaneously on the same Remote Agent. Note: this value is different from the value set by the OMSUBMIT_MAX_USER_PROC variable, which controls how many simultaneous Workflow processes can be run on a Remote Agent, or better known as parallelized processes.

By configuring and defining your Remote Agents to server pools you can easily maximize server resources which will improve your workflow performance and speed.

Blog: Build Environment Variables

Mon, 01 May 2017 00:00:00 +0000

Build Environment Variables and how to manage the details.

Build Environment Variables are critical, detailed pieces of the over build process. If you are using OpenMake Meister to manage your build you can also manage specific Environment Variables for each step. You can also define Global variables for all steps. In both the Configure Machine Environment and Configure Activity Environment fields of OpenMake Meister, you can define either variables and/or scripts to configure the environment that your machine or Workflow Activity work within. Global configuration settings are the default for all Workflow Activities on all machines unless you override them at this level.

Configurations set at the machine level will be the default for all Workflow Activities on that machine unless you override them at the Workflow Activities level. You can set both machine- and Workflow Activities level configurations on the Activities Tab screen. When you select a machine, Configure Machine Environment appears; likewise, when you select a Workflow Activity listed under the machine, Configure Activity Environment appears.

To Sum It Up

So in summary, you can set Environment Variables at 3 levels, the highest level is the Global setting. Defines the Variable for all machines and Workflow Activities. Secondly, you can define them at the machine or Server Pool level, and all Activities running on that machine or Server Pool will use those variables. And within an Activity, you can assign Variables to that specific Activity. In our 7.5 release we will be adding an Environment Library so you can store configurations in the library and assign the library name at the Global, Workflow Activity or Machine (Server Pool) level. This allows you to more easily manage the Environment Variables and reuse them across Activities and Servers.

Blog: LDAP Group Members using ldapsearch and Java

Thu, 13 Apr 2017 00:00:00 +0000

Using ldapsearch with LDAP Group Members.

Ldapsearch has become a handy tool for us. Here is how we use it. Many of our customers are striving to protect a single sign-on, so LDAP becomes critical to achieving their goals. We’ve done quite a bit of work around LDAP coding. The use of ldapsearch has become a popular part of our coding. I thought it would be helpful to expose has we have used it for our applications.

We use the LDAP server provided by Forum Systems Online LDAP Test Server.

Here is the ldapsearch command line:

ldapsearch -W -h ldap.forumsys.com -D "cn=read-only-admin,dc=example,dc=com" -b "dc=example,dc=com" "ou=mathematicians"

-W : Prompt for password

-h : ldap server to use

-D : is the binddn (userid to login to the ldap server with)

-b : is the base search root and the last parameter is the search filter

Results from the ldapsearch:

Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: ou=mathematicians
# requesting: ALL
#

# mathematicians, example.com
dn: ou=mathematicians,dc=example,dc=com
uniqueMember: uid=euclid,dc=example,dc=com
uniqueMember: uid=riemann,dc=example,dc=com
uniqueMember: uid=euler,dc=example,dc=com
uniqueMember: uid=gauss,dc=example,dc=com
uniqueMember: uid=test,dc=example,dc=com
ou: mathematicians
cn: Mathematicians
objectClass: groupOfUniqueNames
objectClass: top

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Here is the same ldap query using Java:

import java.util.ArrayList;
import java.util.Hashtable;
import java.util.Vector;

import javax.naming.Context;
import javax.naming.NameNotFoundException;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
import javax.naming.directory.Attribute;
import javax.naming.directory.Attributes;
import javax.naming.directory.SearchControls;
import javax.naming.directory.SearchResult;
import javax.naming.ldap.InitialLdapContext;
import javax.naming.ldap.LdapContext;

public class memberof
{
 public static void main(String\[\] args)
 {
  ArrayList members = new ArrayList();

  String ldapUsername = "cn=read-only-admin,dc=example,dc=com";
  String ldapPassword = "password";
  String servername = "ldap://ldap.forumsys.com:389";
  String searchbase = "dc=example,dc=com";
  String searchfilter = "ou=mathematicians";

  Hashtable<String, Object> env = new Hashtable<String, Object>();
  env.put(Context.SECURITY\_AUTHENTICATION, "simple");
  env.put(Context.SECURITY\_PRINCIPAL, ldapUsername);
  env.put(Context.SECURITY\_CREDENTIALS, ldapPassword);
  env.put(Context.INITIAL\_CONTEXT\_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
  env.put(Context.PROVIDER\_URL, servername);

  // the following is helpful in debugging errors
  // env.put("com.sun.jndi.ldap.trace.ber", System.err);

  LdapContext ctx;
  try
  {
   ctx = new InitialLdapContext(env, null);

   NamingEnumeration results = null;
   try
   {
    SearchControls controls = new SearchControls();
    controls.setSearchScope(SearchControls.SUBTREE\_SCOPE);
    results = ctx.search(searchbase, searchfilter, controls);

    while (results.hasMore())
    {
     SearchResult searchResult = (SearchResult) results.next();
     Attributes attributes = searchResult.getAttributes();
     Attribute attr = attributes.get("uniqueMember");
     
     for (int i=0;i<attr.size();i++)
     {
      members.add((String) attr.get(i));
     }
    }
   }
   catch (NameNotFoundException e)
   {
    // The base context was not found.
    // Just clean up and exit.
   }
   catch (NamingException e)
   {
    throw new RuntimeException(e);
   }
   finally
   {
    if (results != null)
    {
     try
     {
      results.close();
     }
     catch (Exception e)
     {
      // Never mind this.
     }
    }
    if (ctx != null)
    {
     try
     {
      ctx.close();
     }
     catch (Exception e)
     {
      // Never mind this.
     }
    }
   }

   // Loop through the memebers of the and print them out
   for (int i = 0; i < members.size(); i++)
   {
    System.out.println(members.get(i));
   }
  }
  catch (NamingException e1)
  {
   // TODO Auto-generated catch block
   e1.printStackTrace();
  }
 }
}

Results from the Java program:

uid=euclid,dc=example,dc=com
uid=riemann,dc=example,dc=com
uid=euler,dc=example,dc=com
uid=gauss,dc=example,dc=com
uid=test,dc=example,dc=com

Blog: Dot Net Solution Builds with Complex Dependencies

Fri, 09 Dec 2016 00:00:00 +0000

Dot Net Solution builds are Complicated with Multiple Solution Files.

We often get customers who have multiple Dot Net Solutions for creating a single application. While Microsoft may advise against the practice, large companies tend to push the limit in software development requiring that more than one Dot Net solution file be used. The .Net IDE cannot handle this requirement, which is were we come in.

OpenMake Meister can support the building of multiple Dot Net solution files, treating them as one big Dot Net solution file. By doing this it resolves all cross solution dependencies delivering incremental builds and deploys, and accelerated .Net builds using parallel build processing.

If you need to execute a full build of multiple solutions in Meister, you simply use the .Net plug-in to create a Meister Target file for each .Net Project in the solution. Meister will then generate a build control file that contains all projects for all solutions. It uses MSBuild to execute the compile/link, but it manages the dependencies, incremental processing and parallel builds across the projects.

For companies who are doing large .Net builds with multiple solutions, we have seen speed improvement of up to 50% over what other build management solutions can offer such as IBM UBuild. These solutions cannot do incremental builds or build in parallel. What they do instead is have you write Nant scripts, break up the solution compiles onto different machines, and build circular until you have come to the end. Not very efficient, but the best that can be done without doing any type of real intelligence work on the dependencies. Products offered by Electric Cloud cannot help with this type of problem as well. They depend on the use of GnuMake or old Nmake files that are not used by the .Net framework.

So the good news is there is a strong solution for managing multiple solution .Net files.

OpenMake Meister – OpenMake Meister

Blog: Software Build Automation Done Like Google Rock Stars

Software Build Automation Rock Stars at Google.

Managing Dependencies

Blog: Complex Compiler Plugins for OpenMake Meister

Compile Plugins for Adobe, Lawson, Cognos, and Others

Lawson

Adobe Flex

PeopleSoft Cobol Native Runtime

PowerGen

Actuate6

Cognos Powerhouse Compile Takes

Informix 4ge Executable .4ge

Informix Archive Library

Informix 4ge Executable

Informix Form Compiler .frm

Informix noext Executable .noext

Informix Object

Informix Shared Library. .so

Support Database Management in Your Software Compiles

Oracle Cobol Exe

Oracle Exe

Oracle Forms

Oracle Form Library

Oracle PSQL

Oracle Report

Oracle TDF

Oracle Request Router

Sybase ASE 12.5 and Greater

Sybase ASE pre-12.5

DB2 Exe

DB2 shared library

Linux and UNIX Compile Plugins for Complex Builds

AcuCobol 32 Executable

Archive Library

Microfocus Cobol Executable

COBOL Native Runtime

GNU Archive Library

GNU CPP Executable

GNU Executable

GNU LD Shared Library

GNU Oracle ProC Executable

GNU PIC Archive Library

GNU PIC Executable

GNU PIC Oracle Executable

GNU Shared Library

ITHISAM

LD Shared Library

LD Shared Object

Lex and Flex C File

Lex C Header File

Visual Age C Project Archive Library

Visual Age C Project Executable

PIC Archive Library

PIC Executable

PIC Oracle Executable

Compile Plugins to Support Complex Microsoft Builds

.NET 2005 Dynamic Link Library

.NET 2005 Solution Dynamic Link Library

.NET 2005 Solution Executable

.NET C-Sharp Dynamic Link Library

.NET C-Sharp Executable

.NET C-Sharp Module

.NET ISAPI Extended Dll Shared

.NET ISAPI Extended Dll Static

.NET Managed CPP Class Library

.NET MFC ActiveX Control Shared Creates

.NET MFC ActiveX Control Static

.NET MFC Dll Shared

.NET MFC Dll Static

.NET MFC Exe Shared

.NET MFC Exe Static

.NET Solution Installer

.NET Visual Basic Dll

.NET Visual Basic Exe

.NET Win32 Console Shared

.NET Win32 Console Static

MFC AppWizard Dll Shared

MFC AppWizard Dll Static

MFC AppWizard Exe Shared