{"id":28749691,"url":"https://github.com/psigen/mpc","last_synced_at":"2025-06-16T20:44:09.177Z","repository":{"id":12078121,"uuid":"14665588","full_name":"psigen/mpc","owner":"psigen","description":"The Makefile, Project and Workspace Creator.","archived":false,"fork":false,"pushed_at":"2014-11-20T16:01:27.000Z","size":4760,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2023-04-08T04:47:46.199Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://www.cs.wustl.edu/~schmidt/ACE.html","language":"Perl","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/psigen.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2013-11-24T17:30:50.000Z","updated_at":"2014-11-20T16:01:27.000Z","dependencies_parsed_at":"2022-09-03T14:30:26.720Z","dependency_job_id":null,"html_url":"https://github.com/psigen/mpc","commit_stats":null,"previous_names":[],"tags_count":0,"template":null,"template_full_name":null,"purl":"pkg:github/psigen/mpc","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/psigen%2Fmpc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/psigen%2Fmpc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/psigen%2Fmpc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/psigen%2Fmpc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/psigen","download_url":"https://codeload.github.com/psigen/mpc/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/psigen%2Fmpc/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":260236349,"owners_count":22979404,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-06-16T20:44:08.339Z","updated_at":"2025-06-16T20:44:09.080Z","avatar_url":"https://github.com/psigen.png","language":"Perl","funding_links":[],"categories":[],"sub_categories":[],"readme":"$Id$\n\n.:: 3/13/2002 ::.\n\nThe Makefile, Project and Workspace Creator.\nDesigned by Justin Michel (michel_j@ociweb.com) and Chad Elliott.\nImplemented by Chad Elliott (elliott_c@ociweb.com).\n\nA single tool (MPC) can be used to generate tool specific input (i.e.,\nMakefile, dsp, vcproj, etc.)  The generator takes platform and building\ntool generic files (mpc files) as input which describe basic information\nneeded to generate a \"project\" file for various build tools.  These tools\ninclude Make, NMake, Visual C++ 6, Visual C++ 7, etc.\n\nOne of the many unique and useful features of the Makefile, Project and\nWorkspace Creator is that the project definition files can employ the idea\nof inheritance.  This feature allows a user to set up a basic base project\n(mpb file) that can contain information that is applicable to all\nsub-projects.  Things such as include paths, library paths and inter-project\ndependencies could be described in this base project and any project that\ninherits from it would contain this information as well.\n\nAnother set of files, known as template input files (mpt files), provides\nthe generator with the necessary information to fill platform and build tool\nspecific information for dynamic and static library and binary executable\nprojects.\n\nTogether, the generic input files and the template input files are applied\ntoward a platform and build specific template (mpd file) to create the final\nproduct (a build tool specific input file).  These templates contain\n\"variables\" that are filled in by the project creator with information\ngathered through the mpc and mpt files and possibly by default values set\nwithin the template itself.\n\nWorkspaces are defined by providing a list of mpc files in a single (mwc)\nfile.  For each mpc file specified, the workspace creator (mwc.pl) calls\nupon the project creator to generate the project.  After all of the projects\nare successfully generated, the tool specific workspace is generated\ncontaining the projects and any defined inter-project dependency information\n(if supported by the build tool).  If no workspace files are provided to the\nworkspace creator, then the current directory is traversed and any mpc files\nlocated will be part of the workspace that is generated.\n\n\nWorkspace Declarations\n----------------------\n\nworkspace(workspace_name) {\n  file.mpc\n  directory\n  relative/path/to/another/mwc_file\n}\n\nWorkspaces can contain individual mpc files, directories or other mwc files.\nIn the case of a directory, the workspace creator will traverse it and use\nany mpc files that are found.  If another workspace file is listed in the\nworkspace files, it will be aggregated into the workspace with paths relative\nto the directory in which the main workspace is found.  These \"aggregated\"\nworkspaces should not inherit from any other base workspace.  The workspace\nfiles should have an 'mwc' extension.\n\nYou can exclude directories and .mpc files from a workspace using the 'exclude'\nscope operator:\n\nworkspace {\n  dir1\n  dir2\n\n  // exclude this_dir for all project types\n  exclude {\n    dir2/this_dir\n  }\n\n  // exclude other_dir for vc6, vc71, vc8, and vc9 types\n  exclude(vc6, vc71, vc8, vc9) {\n    dir2/other_dir\n  }\n\n  // exclude unix_only for every type except gnuace and make\n  exclude(!gnuace, !make) {\n    dir2/unix_only\n  }\n\n  // exclude non_window for every windows project type\n  exclude(prop:windows) {\n    dir2/non_windows\n  }\n\n  // exclude microsoft_only for all non-microsoft project types\n  exclude(!prop:microsoft) {\n    dir2/microsoft_only\n  }\n\n  dir3\n\n  // Associate the name \"other\" with dir3\n  associate(other) {\n    dir3\n  }\n\n  specific(rpmspec) {\n    rpm_version = 1.0\n  }\n}\n\nThe associate scope associates a name with one or more directories.\nThis does not add directories to a workspace, it only makes an\nassociation.  This may or may not have an effect on the generated\nworkspace; it depends solely upon whether the project type supports\nassociations.\n\nCurrently automake is the only project type that supports associations.\nEach directory listed under an association is grouped together and\nbuilt conditionally based on the association name.\n\nWorkspaces support a 'specific' clause conceptually and syntactically similar\nto the project 'specific' clause, described below.  Any variables assigned\nwithin the clause are only available to workspaces, not to projects.  Two sorts\nof assignments are possible: first are assignments to the keywords cmdline and\nimplicit (described in the section 'Workspaces', below) and the second are\ntype-specific variables.  Consult the documentation for the type for details on\ntype-specific variables.  Keyword assignments (cmdline and implicit) impact the\nentire workspace, not just the 'specific' scope.\n\nFinally, prop:value are properties in MPC. They are used to group\ntogether common workspace/project types. More details on properties\nin MPC can be found in the section on the 'specific' keyword in the\nProject Declarations section below.\n\nProject Declarations\n--------------------\n\nproject(project_name) : baseproject, anotherbaseproject {\n  exename   = foo\n  includes += \".\"\n  libpaths  = directory\n\n  Source_Files {\n    file1.cpp\n    file2.cpp\n    .\n    .\n    fileN.cpp\n  }\n\n  Header_Files {\n    file1.h\n    file2.h\n    .\n    .\n    fileN.h\n  }\n}\n\n\nMPC expects all files to be listed with forward slashes (/) if a file name\ncontains a directory.  Providing files with back slashes (\\) can cause\nunexpected results during generation.\n\nWhen listing files within components (Source_Files, Header_Files, etc.), you\ncan use wild cards (*?[]) to include groups of files as can be done in shells.\nYou can exclude files by preceding the name (or wild card) with the '!', but\nthis sort of exclusion only pertains to files that exist in the directory at\nthe time of project generation.  There is an additional syntax similar to\nthe '!' ('^') which works the same as the '!' except that after all of the\nsource files are added to the list (after automatic custom generated files\nare added) these files are explicitly removed from the list.\n\nThe (project_name) part of the project declaration is optional.  If it is\nleft off, the project name will default to the name of the mpc file without\nthe extension.  Inheritance is optional.\n\nIf the project name or workspace name contains an asterisk (*) then the\ndefault project (workspace) name will be used in its place.  For example, if\nthe mpc file is named example.mpc and it contains the following:\n\nproject(*client) {\n\nThe project name will be example_client.  If the any part of the modified\nproject (workspace) name contains a capital letter then each word will be\ncapitalized.  For instance, if the above mpc file example was named\nExample.mpc, then the modified project name would be Example_Client.\n\nIf the value set for exename contains an asterisk then the asterisk portion\nof the name will be replaced with the current project name.  The same logic\napplies to sharedname, staticname, after and libs.\n\nIf multiple projects are going to be contained within a single workspace\n(using mwc.pl), there can be no duplication of project names.  This is\ndisallowed due to limitations of some workspace tools.\n\nProject Keywords\n----------------\nexename         Specifies the name of the executable that will be created\nsharedname      Specifies the name of the shared library that will be created\nstaticname      Specifies the name of the static library that will be created\nbuildflags      This keyword can only be used as a source component scoped\n                setting (ie. inside the scope of Source_Files).  It\n                specifies additional build flags that will be passed to the\n                compiler as the source files are being compiled.\ndependent_upon  This keyword can only be used as a header component scoped\n                setting (ie. inside the scope of Header_Files).  It\n                determines which file the header file is dependent\n                upon for vc8, and vc9 only.\ndllout          If defined, specifies where the dynamic libraries will be\n                placed.  This overrides libout in the dynamic case.\nlibout          Specifies where the dynamic and static libraries will be placed\nexeout          Specifies where executables will be placed (Previously known\n                as install)\nmanaged         This keyword can be used as a global setting or as a source\n                component scoped setting (ie. inside the scope of\n                Source_Files).  It specifies that the source files should be\n                compiled as managed C++.  Since this is Microsoft specific, it\n                is only supported by the nmake, vc7, vc71, vc8, vc9, vc10\n                project types.\nno_pch          This keyword can only be used as a source component scoped\n                setting (ie. inside the scope of Source_Files).  It\n                specifies that precompiled headers should not be used for\n                the source files listed within the scope of it's setting.\npch_header      Specifies the precompiled header file name\npch_source      Specifies the precompiled source file name\npostbuild       If this is defined in the project, the value will be\n                interpreted as commands to run after the project has been\n                successfully built.  The \u003c%..%\u003e construct can be used within\n                this value to access template variables and functions of the\n                template parser. In addition, the following pseudo variables\n                can be used.\n\n                  \u003c%cat%\u003e    - Platform non-specific command to cat a file.\n                  \u003c%cmp%\u003e    - Platform non-specific compare command.\n                  \u003c%cp%\u003e     - Platform non-specific copy command.\n                  \u003c%mkdir%\u003e  - Platform non-specific mkdir command.\n                  \u003c%mv%\u003e     - Platform non-specific move command.\n                  \u003c%os%\u003e     - Returns either win32 or unix.\n                  \u003c%rm%\u003e     - Platform non-specific delete command.\n                  \u003c%rmdir%\u003e  - Platform non-specific recursive directory\n                               delete command.\n                  \u003c%nul%\u003e    - Platform non-specific null device.\n                  \u003c%pathsep%\u003e- Platform non-specific path separator (; or :).\n                  \u003c%gt%\u003e     - Project non-specific greater than sign.\n                  \u003c%lt%\u003e     - Project non-specific less than sign.\n                  \u003c%and%\u003e    - Project non-specific and sign.\n                  \u003c%or%\u003e     - Project non-specific or sign.\n                  \u003c%quote%\u003e  - Project non-specific double quote.\n                  \u003c%slash%\u003e  - Platform non-specific directory separator.\n                  \u003c%equote%\u003e - Project non-specific escaped quote.\n                  \u003c%crlf%\u003e   - Platform non-specific line ending.\n                  \u003c%cmdsep%\u003e - Project/platform non-specific command separator\n                               which always runs the right-hand side command.\nprebuild        This is similar to postbuild except that it will be\n                performed before the build instead of after.\npostclean       This is similar to postbuild except that it will be\n                performed after cleaning up the project (the realclean\n                target for make based project types).  NOTE: This is not\n                used in the IDE based project types since there is no hook\n                for such an action.\nrecurse         If set to 1, MPC will recurse into directories listed under\n                component listings and add any component corresponding files\n                to the list.  This keyword can be used as a global project\n                setting or a component scoped setting.\nversion         Specifies the version number for the library or executable\nmacros          These values will be passed as macros to the compiler.\nlibpaths        Specifies 1 or more locations to find libraries\nrecursive_libpaths Specifies 1 or more locations to find libraries which will\n                be added recursively.\nincludes        Specifies 1 or more locations to find include files\nlibs            Specifies 1 or more libraries to link into the exe or library\nrecursive_includes Specifies 1 or more locations to find include files which\n                will be added recursively.\nlit_libs        Specifies 1 or more libraries to link into the exe or library.\n                If libraries receive a library decorator, then these will not.\npure_libs       Specifies 1 or more libraries to link into the exe or library.\n                The values specified for this variable are passed to the\n                linker unmodified.\nafter           Specifies that this project must be built after 1 or more\n                project names listed.  An extended syntax is available in\n                order to associate name-value pairs with a dependency:\n                \u003cproject name[:name=value]\u003e\n                These name-value pairs may be used in the creation of the\n                dependencies of the project.\ncustom_only     Create a project that contains only custom generation\n                targets (any file type described by a Define_Custom section).\n                This will automatically be set to 1 when a project contains\n                no source or resource files, but does contain custom input\n                files.\ndynamicflags    Specifies preprocessor flags needed for dynamic libraries\nstaticflags     Specifies preprocessor flags needed for static libraries\n\nverbatim        This allows arbitrary information to be place in a generated\n                project file.  The syntax is as follows:\n\n                verbatim(\u003cproject type\u003e, \u003clocation\u003e[, 1]) {\n                  ..\n                  ..\n                }\n\n                When MPC is generating a project of type \u003cproject type\u003e and\n                comes upon a marker that matches the \u003clocation\u003e name, it\n                will place the text found inside the construct directly into\n                the generated project.  If the third and optional parameter is\n                passed and is true, the verbatim section will be added to\n                existing verbatim settings at the same location.  If you need\n                to preserve white space, the line or lines should be placed\n                inside double quotes.\n\nspecific        This scope allows assignments that are specific to a\n                particular project type or property.  The syntax is as\n                follows:\n\n                specific(\u003cproj_type|prop:prop_name\u003e [, \u003cproj_type|prop:prop_name\u003e ...]) {\n                  lit_libs += c\n                  ...\n                }\n\n                or\n\n                specific(\u003cproj_type|prop:prop_name\u003e [, \u003cproj_type|prop:prop_name\u003e ...]) {\n                  lit_libs += c\n                  ...\n                } else {\n                  lit_libs += c_other\n                  ...\n                }\n\n                If the else is provided, it is required to be on\n                the same line as the closing curly brace.  You may\n                also negate the project type (using '!') which will cause\n                the specific to be evaluated for all types except the type\n                specified.\n\n                The following property names are available: borland, make,\n                microsoft, windows, and static.  The table below shows which\n                properties apply to which project types.  The static\n                property will be set if the -static option was supplied.\n                Additionally, a property that corresponds to the language\n                will be set (e.g., cplusplus, csharp, java, vb).\n\n                         | borland | make | microsoft | windows |\n                ---------+---------+------+-----------+---------|\n                automake |         |  X   |           |         |\n                bcb2007  |    X    |      |           |    X    |\n                bcb2009  |    X    |      |           |    X    |\n                bds4     |    X    |      |           |    X    |\n                bmake    |    X    |  X   |           |    X    |\n                cc       |         |      |           |    X    |\n                em3      |         |      |     X     |    X    |\n                ghs      |         |      |           |    ?    |\n                make     |         |  X   |           |         |\n                nmake    |         |  X   |     X     |    X    |\n                vc6      |         |      |     X     |    X    |\n                vc7      |         |      |     X     |    X    |\n                vc71     |         |      |     X     |    X    |\n                vc8      |         |      |     X     |    X    |\n                vc9      |         |      |     X     |    X    |\n                vc10     |         |      |     X     |    X    |\n                vc11     |         |      |     X     |    X    |\n                vc12     |         |      |     X     |    X    |\n                wix      |         |      |           |    X    |\n\n                ? - indicates that this is controled by the MPC_GHS_UNIX\n                environment variable.\n\n                If a keyword is not recognized as a valid MPC keyword, it is\n                interpreted as a template value modifier.  In this\n                situation, this construct has the exact same restrictions as\n                the -value_template command line option.  See the USAGE file\n                for more information.\n\n                Scopes are available in some of the MPC templates.  These\n                scopes are created by using a template variable within a\n                \u003c%foreach%\u003e context.  The scope will be, one at a time, each\n                space separated words within the template variable value.\n                Variables can be modified using a scope modifier.  For\n                example, the word 'FOO' will be added to the template\n                variable 'defines' when it is seen in the 'Debug' scope:\n\n                specific {\n                  Debug::defines += FOO\n                }\n\nexpand          This scope allows the specification for a variable that is\n                found within $() to be expanded from the list of possible\n                values.  These possible values can contain environment\n                variables (specified by $VAR_NAME) and plain text.  If a\n                possible value contains an environment variable and that\n                variable is defined then this value is used to expand the\n                $() variable.  If the environment variable is not defined\n                then this possible value is not used.  The syntax is as\n                follows:\n\n                expand(\u003cvariable name\u003e) {\n                  \u003cpossible value 1\u003e\n                  .\n                  .\n                  \u003cpossible value n\u003e\n                }\n\nconditional     This scope allows addition of source files conditionally\n                based on a particular project type or property as describe\n                in the 'specific' section.  The syntax is as follows:\n\n                conditional(\u003cproj_type|prop:prop_name\u003e [, \u003cproj_type|prop:prop_name\u003e ...]) {\n                  source1.cpp\n                  ...\n                }\n\n                or\n\n                conditional(\u003cproj_type|prop:prop_name\u003e [, \u003cproj_type|prop:prop_name\u003e ...]) {\n                  source1.cpp\n                  ...\n                } else {\n                  source2.cpp\n                  ...\n                }\n\n                If the else is provided, it is required to be on\n                the same line as the closing curly brace.  You may\n                also negate the project type (using '!') which will cause\n                the conditional to be evaluated for all types except the\n                type specified.\n\nrequires        Specifies which features should be enabled in order to\n                generate the project file.\navoids          Specifies which features should be disabled in order to\n                generate the project file.\nwebapp          Determines whether the project is a Web Application or not.\n                A web application project will have no project file written\n                but the information will be included in the workspace (if\n                web applications are supported by the project type).\n\nC# Specific Project Keywords\n----------------------------\ndependent_upon  This can only be applied to source and resx components.  It\n                determines which file the source or resx file is dependent\n                upon for vc8, vc9, and vc10 only.\ngenerates_source This can only be applied to resx components.  It indicates\n                that the resx file or files auto generates a source file for\n                vc8, vc9, and vc10 only.  A value of '1' indicates that the\n                resx file generates a source file and the default generator is\n                used. Any other value indicates that the resx file generates a\n                source file and the generator name is taken from the value\n                supplied.  The auto generated name is created by taking the\n                resx file without the extension and appending .Designer.cs.\nsubtype         This can only be applied to source and resx components.  It\n                determines the SubType setting for vc8, vc9, and vc10 only.\n\nCustom File Definitions\n-----------------------\nIn order to support a variety of custom build rules, MPC allows you to\ndefine your own custom file types.  Below is an example of a custom\ndefinition.\n\nproject {\n  Define_Custom(MOC) {\n    automatic_in     = 0\n    automatic_out    = 0\n    command          = $(QTDIR)/bin/moc\n    postcommand      = echo \u003c%quote%\u003e#include \u003c%lt%\u003esome.h\u003c%gt%\u003e\u003c%quote%\u003e \u003c%gt%\u003e \u003c%temporary%\u003e \u003c%and%\u003e \\\n                       \u003c%cat%\u003e \u003c%output%\u003e \u003c%gt%\u003e\u003c%gt%\u003e \u003c%temporary%\u003e \u003c%and%\u003e \\\n                       \u003c%mv%\u003e \u003c%temporary%\u003e \u003c%output%\u003e\n    output_option    = -o\n    inputext         = .h\n    pre_extension    = _moc\n    source_outputext = .cpp\n  }\n\n  MOC_Files {\n    QtReactor.h\n  }\n\n  Source_Files {\n    QtReactor_moc.cpp\n  }\n}\n\nThe above example defines a custom file type \"MOC\" which describes basic\ninformation about how to process the input files and what output files are\ncreated.  Once the custom file type is defined, MOC_Files can be defined in\norder to specify the input files for this new file type.\n\nDefine_Custom definitions may use single inheritance.  This is useful for\ncreating aliased names:\n  Define_Custom(QtMOC) : MOC {\n  }\n\nHere is a list of keywords that can be used within the scope of\nDefine_Custom or Modify_Custom:\n\nautomatic           This keyword is deprecated.  Use automatic_in and\n                    automatic_out instead.\nautomatic_in        If set to 1, then attempt to automatically determine\n                    which files belong to the set of input files for the\n                    custom type.  If set to 0, then no files are\n                    automatically added to the input files.  If omitted,\n                    automatic_in is assumed to be 1.\nautomatic_out       If set to 1, then attempt to automatically determine\n                    which generated files belong to the set of components\n                    (e.g., Source_Files, Header_Files, etc.) based on the\n                    type of file generated from the custom command.  If set\n                    to 0, then no files are automatically added to the\n                    various components.  If omitted, automatic_out is\n                    assumed to be 1.\ncommand             The name of the command that should be used to process\n                    the input files for the custom type.\ncommandflags        Any options that should be passed to the command go here.\ndependent           If this is given a value, then a dependency upon that\n                    value will be given to all of the generated files.\n                    The default for this is unset and no dependency will be\n                    generated.\ndependent_libs      If this is given a value, then a dependency upon that\n                    library value will be given to all of the generated files.\n                    The format for this entry should be the basename for the\n                    library (no library prefix, postfix, or extension)\n                    preceded by any relative or absolute path to the library.\n                    The typical use for this would be so that a project is\n                    rebuilt when a library needs to be rebuilt for its\n                    dependent executable. The default for this is unset and no\n                    dependency will be generated.\ninputext            This is a comma separated list of input file extensions\n                    that belong to the command.\nkeyword             This is a special assignment that takes the form of the\n                    following:\n\n                    keyword newname = existing_custom_name\n\n                    This has the effect of mapping newname to be the\n                    same as existing_custom_name.  existing_custom_name,\n                    which is optional, corresponds to one of the keywords\n                    available within a Define_Custom scope (except for\n                    keyword).  This function puts newname into the project\n                    level scope such that it can be used outside of the\n                    scope of the particular custom file type being defined.\n                    It should be noted that the mapped keywords can not be\n                    used within the scope of a 'specific' clause.  It does\n                    not cause an error, but it has absolutely no affect.\n                    If existing_custom_name is not supplied, then the only\n                    way to utilize the newname value is from within the\n                    template code. ex. \u003c%newname%\u003e\nlibpath             If the command requires an additional library path, add\n                    it here.\noutput_option       If the command takes an option to specify only a single\n                    file output name, then set it here.  Otherwise, this\n                    should be omitted.\noutput_follows_input This setting defaults to 1 and indicates that output\n                    files from the custom command will end up in the same\n                    directory as the input files.  If this is set to 0, it\n                    is assumed that the output files will go into the same\n                    directory as the .mpc file.\npch_postrule        If this is set to 1, then a rule will be added to the\n                    custom rule that will modify the source output files to\n                    include the precompiled header file.\npostcommand         Allows a user to execute arbitrary commands after\n                    the main command is run to generate the output file.\n                    The following pseudo variables can be accessed from\n                    within the postcommand assignment:\n                    \u003c%input%\u003e     - The input file for the original command.\n                    \u003c%output%\u003e    - The output created by the original command.\n                    \u003c%input_basename%\u003e  - The basename of the input file.\n                    \u003c%input_dirname%\u003e   - The directory of the input file.\n                    \u003c%input_noext%\u003e     - The input file with no extension.\n                    \u003c%output_basename%\u003e - The basename of the output file.\n                    \u003c%output_dirname%\u003e  - The directory of the output file.\n                    \u003c%output_noext%\u003e    - The output file with no extension.\n                      The output file can be referenced as a generic output\n                      file using \u003c%output%\u003e or can be referenced as a\n                      component file (if it matches the particular type)\n                      using one of the following:\n\n                        \u003c%source_file%\u003e\n                        \u003c%template_file%\u003e\n                        \u003c%header_file%\u003e\n                        \u003c%inline_file%\u003e\n                        \u003c%documentation_file%\u003e\n                        \u003c%resource_file%\u003e\n\n                      The output file without an extension can be referenced\n                      as a generic output file using \u003c%output_noext%\u003e or can\n                      be referenced as a component file (if it matches the\n                      particular type) using one of the following:\n\n                        \u003c%source_file_noext%\u003e\n                        \u003c%template_file_noext%\u003e\n                        \u003c%header_file_noext%\u003e\n                        \u003c%inline_file_noext%\u003e\n                        \u003c%documentation_file_noext%\u003e\n                        \u003c%resource_file_noext%\u003e\n\n                      The following are also available for use within the\n                      postcommand setting.  They return the extension (if\n                      there is any) of the input and output files\n                      respectively:\n\n                        \u003c%input_ext%\u003e\n                        \u003c%output_ext%\u003e\n\n                    The following pseudo template variables, in addition to\n                    all project settings, are valid for use within the\n                    command, commandflags, dependent, postcommand and\n                    output_option settings:\n\n                    \u003c%and%\u003e       - Project non-specific and sign.\n                    \u003c%cat%\u003e       - Platform non-specific command to cat a file.\n                    \u003c%cmdsep%\u003e    - Project/platform non-specific command\n                                    separator which always runs the right-hand\n                                    side command.\n                    \u003c%cp%\u003e        - Platform non-specific copy command.\n                    \u003c%gendir%\u003e    - The output directory specified by the\n                                    gendir setting.\n                    \u003c%gt%\u003e        - Project non-specific greater than sign.\n                    \u003c%lt%\u003e        - Project non-specific less than sign.\n                    \u003c%nul%\u003e       - Platform non-specific null device.\n                    \u003c%mkdir%\u003e     - Platform non-specific mkdir command.\n                    \u003c%mv%\u003e        - Platform non-specific move command.\n                    \u003c%or%\u003e        - Project non-specific or sign.\n                    \u003c%quote%\u003e     - Project non-specific double quote.\n                    \u003c%rm%\u003e        - Platform non-specific delete command.\n                    \u003c%temporary%\u003e - A temporary file name.\n                    \u003c%prj_type%\u003e  - The project type supplied by the -type\n                                    option.\n\n                    The following psuedo template variables will be set to\n                    the known extension for Windows and empty on non-Windows\n                    based project types.\n\n                    \u003c%bat%\u003e       - The extension for batch files.\n                    \u003c%cmd%\u003e       - The extension for command files.\n                    \u003c%exe%\u003e       - The extension for executable files.\n\n                    If any referenced pseudo template variable does\n                    not contain a value, then the particular setting\n                    (command, commandflags, dependent, postcommand or\n                    output_option) will not be used.\n\n                    It should also be noted that use of automatically\n                    generated project settings, such as sharedname, exename,\n                    etc., may not exist at the time that a project setting\n                    is evaluated and will end up empty.  To avoid this\n                    situation, explicitly set project settings that are\n                    going to be used within this context.\npre_extension       If the command produces multiple files of the same\n                    extension, this comma separated list can be used to\n                    specify them.  For example, tao_idl creates two types of\n                    files per extension (C.h, S.h, C.cpp, S.cpp, etc).\nsource_pre_extension        This is the same as pre_extension except that it\n                            only applies to source files.\ninline_pre_extension        This is the same as pre_extension except that it\n                            only applies to inline files.\nheader_pre_extension        This is the same as pre_extension except that it\n                            only applies to header files.\ntemplate_pre_extension      This is the same as pre_extension except that it\n                            only applies to template files.\nresource_pre_extension      This is the same as pre_extension except that it\n                            only applies to resource files.\ndocumentation_pre_extension This is the same as pre_extension except that it\n                            only applies to documentation files.\ngeneric_pre_extension       This is the same as pre_extension except that it\n                            only applies to generic files.\npre_filename                This is similar to pre_extension except that the values\n                            are prepended to the file name instead of the extension.\nsource_pre_filename         This is the same as pre_filename except that it\n                            only applies to source files.\ninline_pre_filename         This is the same as pre_filename except that it\n                            only applies to inline files.\nheader_pre_filename         This is the same as pre_filename except that it\n                            only applies to header files.\ntemplate_pre_filename       This is the same as pre_filename except that it\n                            only applies to template files.\nresource_pre_filename       This is the same as pre_filename except that it\n                            only applies to resource files.\ndocumentation_pre_filename  This is the same as pre_filename except that it\n                            only applies to documentation files.\ngeneric_pre_filename        This is the same as pre_filename except that it\n                            only applies to generic files.\npre_dirname                 This is similar to pre_filename except that the\n                            value is prepended to the directory portion of\n                            the file name instead of the file name itself.\n                            If a separate directory is desired, the\n                            pre_dirname setting should end in a slash.\nsource_pre_dirname          This is the same as pre_dirname except that it\n                            only applies to source files.\ninline_pre_dirname          This is the same as pre_dirname except that it\n                            only applies to inline files.\nheader_pre_dirname          This is the same as pre_dirname except that it\n                            only applies to header files.\ntemplate_pre_dirname        This is the same as pre_dirname except that it\n                            only applies to template files.\nresource_pre_dirname        This is the same as pre_dirname except that it\n                            only applies to resource files.\ndocumentation_pre_dirname   This is the same as pre_dirname except that it\n                            only applies to documentation files.\ngeneric_pre_dirname         This is the same as pre_dirname except that it\n                            only applies to generic files.\nsource_outputext    This is a comma separated list of possible source file\n                    output extensions.  If the command does not produce\n                    source files, then this can be omitted.\ninline_outputext    This is a comma separated list of possible inline file\n                    output extensions.  If the command does not produce\n                    inline files, then this can be omitted.\nheader_outputext    This is a comma separated list of possible header file\n                    output extensions.  If the command does not produce\n                    header files, then this can be omitted.\ntemplate_outputext  This is a comma separated list of possible template file\n                    output extensions.  If the command does not produce\n                    template files, then this can be omitted.\nresource_outputext  This is a comma separated list of possible resource file\n                    output extensions.  If the command does not produce\n                    resource files, then this can be omitted.\ndocumentation_outputext  This is a comma separated list of possible\n                         documentation file output extensions.  If the\n                         command does not produce documentation files, then\n                         this can be omitted.\ngeneric_outputext   If the command does not generate any of the other output\n                    types listed above, then the extensions should be listed\n                    under this.\n\nIf the custom output can not be represented with the above output extension\nkeywords (*_outputext) and you have knowledge of the output files a priori,\nyou can represent them with the '\u003e\u003e' construct.\n\nBelow is an example that demonstrates the use of '\u003e\u003e'.  The command takes an\ninput file name of foo.prp and produces two files that have completely\nunrelated filenames (i.e. foo !~ hello).\n\nproject {\n  Define_Custom(Quogen) {\n    automatic_in        = 0\n    automatic_out       = 0\n    command             = perl quogen.pl\n    commandflags        = --debuglevel=1 --language=c++ \\\n                          --kernel_language=c++\n    inputext            = .prp\n    keyword quogenflags = commandflags\n  }\n\n  Quogen_Files {\n    foo.prp \u003e\u003e hello.h hello.cpp\n  }\n\n  Source_Files {\n    hello.cpp\n  }\n}\n\nYou can use the '\u003c\u003c' construct to represent dependencies for specific custom\ninput file.  For instance, in the above example, assume that foo.prp depends\nupon foo.in, we would represent this by adding \u003c\u003c foo.in as shown below.\n\n  Quogen_Files {\n    foo.prp \u003e\u003e hello.h hello.cpp \u003c\u003c foo.in\n  }\n\nThere is a construct that can be used within a Define_Custom section\ncalled 'optional' and can be used to represent optional custom output\ndependent upon particular command line parameters passed to the custom\ncommand.\n\nproject {\n  Define_Custom(TEST) {\n    optional(keyword) {\n      flag_keyword(option) += value [, value]\n    }\n  }\n}\n\nIn the above example, keyword can be any of the pre_extension, pre_filename\nor keywords that end in _outputext.  flag_keyword can be any of the custom\ndefinition keywords, however only commandflags really make any sense.\nInside the parenthesis, the flag_keyword value is searched for the 'option'\nvalue.  If it is found, then the 'value' after the += is added to the list\nspecified by 'keyword'.  This can also be negated by prefixing 'option' with\nan exclamation point (!).\n\nproject {\n  Define_Custom(IDL) {\n    source_pre_extension = C, S\n    optional(source_pre_extension) {\n      commandflags(-GA) += A\n    }\n  }\n}\n\nIn the preceding example, the source_pre_extension contains C and S.  The\noptional clause can be read as follows: If 'commandflags' contains -GA then\nadd A to source_pre_extension.\n\nParticular output extensions are not required.  However at least one output\nextension type is required in order for MPC to generate a target.  Within\ngraphical build environments, the custom input file will be listed\nregardless of the presence of an extension definition.  In this case, the\ninput file will be \"excluded\" from the build.\n\nFor custom file types, there are a few keywords that can be used within the\ncustom file type input lists: command, commandflags, dependent,\ndependent_libs, gendir and postcommand.  These keywords (except for gendir)\ncan be used to augment or override the values of the same name defined in a\nDefine_Custom section. gendir can be used to specify the directory in which\nthe generated output will go.  Below is an example:\n\n  MOC_Files {\n    commandflags += -nw\n    gendir = moc_generated\n    QtReactor.h\n  }\n\n  Source_Files {\n    moc_generated/QtReactor_moc.cpp\n  }\n\nIn the above example, the generated file (QtReactor_moc.cpp) is placed in\nthe moc_generated directory and the -nw option is added to commandflags.\nIt should be noted that if the custom file definition does not set the\noutput_option then you must provide the necessary options in\ncommandflags to ensure that the generated output goes into the directory\nspecified by gendir.\n\nThe following example illustrates the use of the keyword mapping capability\nof the Define_Custom:\n\nproject {\n  Define_Custom(CIDL) {\n    automatic_in      = 0\n    automatic_out     = 0\n    command           = $(CIAO_ROOT)/bin/cidlc\n    commandflags      = -I$(TAO_ROOT)/tao -I$(TAO_ROOT)/orbsvcs/orbsvcs --\n    inputext          = .cidl\n    source_outputext  = _svnt.cpp\n    generic_outputext = E.idl\n\n    // Allow cidlflags to be used outside the scope of CIDL_Files\n    keyword cidlflags = commandflags\n  }\n\n  // This will get added to all commandflags for CIDL_Files\n  cidlflags += --some_option\n\n  CIDL_Files {\n    // This will have a combination of the original commandflags plus\n    // the value added to cidlflags above.\n    file.cidl\n  }\n\n  CIDL_Files {\n    // This will have a combination of the original commandflags plus\n    // the value added to cidlflags above plus the value added to\n    // cidlflags here.\n    cidlflags += --another_option\n    another_file.cidl\n  }\n}\n\nA Modify_Custom section can be used to modify an existing custom definition.\nThe Define_Custom must be processed prior to processing a Modify_Custom\nsection; otherwise, an error will occur.\n\nSpecial type of feature project\n-------------------------------\nA feature project contains information as a project would, but can only\nbe a base project and will only be added to a sub project if the features\nthat it requires (or avoids) are present.\n\nA feature definition requires at least one feature name.  A name by itself\nspecifies that the feature is required.  A '!' in front of the feature name\nindicates that the feature must be disabled.  There may be more than one\nfeature listed between the parenthesis and they must be comma separated.\nEach feature will be logically anded together.\n\nThe following feature definition requires that the qt feature be enabled.\n\nfeature(qt) {\n  Define_Custom(MOC) {\n    automatic_in     = 0\n    automatic_out    = 0\n    command          = $(QTDIR)/bin/moc\n    output_option    = -o\n    inputext         = .h\n    pre_extension    = _moc\n    source_outputext = .cpp\n  }\n\n  MOC_Files {\n    QtSpecific.h\n  }\n\n  Source_Files {\n    QtSpecific_moc.cpp\n  }\n}\n\nAssuming that the above feature definition is stored in a file named\nqt_specific.mpb, an mpc project could inherit from it and would only receive\nthe feature definition if the qt feature was enabled.\n\nproject: qt_specific {\n  ...\n}\n\n\nFeature Files\n-------------\nFeatures are enabled and disable within feature files or through the use of\nthe -features option (see USAGE for more details).  The first feature file\nread is always global.features found in the config directory.  The second\nfeature file read is the project type name with .features appended\n(ex. vc71.features, make.features, etc.) which must be located in the same\ndirectory as the global.features file.  Lastly, the file specified by the\n-feature_file option is read if this option is used.\n\nEach successive feature file has precedence over the previous.  That is,\nif a feature has already been set previously it is overridden.  The\n-features option has precedence over feature files.\n\nSpecial Keywords Available to Templates\n---------------------------------------\nproject_name    This contains the name of the project.\nproject_file    This contains the name of the output file.\nguid            This is used by the VC7 project and workspace creator.\nconfigurations  When used within a foreach context, this info (each\n                configuration) is gathered for use with the VC7 workspace\n                creator.\nflag_overrides  Used to determine flags that have been overridden on a per\n                file basis.\ncustom_types    The list of custom file types that may have been defined\n                in the mpc file or a base project.\nfornotlast      Insert the text on every foreach iteration except the last.\nforlast         Insert the text only on the last foreach iteration.\nfornotfirst     Insert the text on every foreach iteration except the first.\nforfirst        Insert the text only on the first foreach iteration.\nforcount        By default, a one based index number of the foreach\n                iterations.  The base can be modified by providing a base\n                number in the foreach as in the following examples:\n\n\u003c%foreach(4, includes)%\u003e\n  ...\n\u003c%endfor%\u003e\n\n\n\u003c%foreach(include, 4, includes)%\u003e\n  ...\n\u003c%endfor%\u003e\n\nIf the list variable ('includes' in the above example) is a function call,\nit is necessary to provide both a variable name and a base count number.\n\nProject Variable and Template Input Variable Interaction\n--------------------------------------------------------\nProject variables and template input variables are separate entities and in\nthe context of the TemplateParser, template input variables have precedence\nover project variables.\n\nThis means that if the project keyword 'libout' is set in an MPC project and\nis set as a template input variable, the template input variable value will\nbe used.  There are exceptions to this rule.  The following list shows the\nproject keywords that have their MPC project value appended to the template\ninput value (if there is a template input value).\n\nlibpaths\nincludes\nlibs\nlit_libs\npure_libs\ndynamicflags\nstaticflags\nrequires\navoids\nmacros\n\nWorkspaces\n----------\nWorkspaces (mwc files) can have assignments similar to projects.  There are\ncurrently only two assignments allowed.\n\nThe first is 'cmdline'.  The values given to the cmdline assignment will be\nprocessed as command line options, but only to the projects that are\ncontained within the workspace (or the scope of the assignment).  All\ncommand line options are valid for cmdline, except for the following:\n-exclude, -for_eclipse, -gendot, -gfeature_file, -into, -make_coexistence,\n-noreldefs, and -recurse.\n\nThe second assignment is 'implicit'.  This assignment takes two different\ntypes of values.  It takes a boolean value (0 or 1) to indicate that an\nimplicit project should be created in directories that contain no mpc file,\nbut contain project related files (source, headers, etc.).  The default\nvalue for implicit is 0.  It also takes a character string that represents a\nbase project (similar to the -base option).  In this case, implicit is\nenabled and each implicitly generate project file will have the base project\nor base projects (when addition is used) when the project is created.\n\nDefaulting Behavior\n-------------------\n1) If a project name is not specified:\n\n   it will be defaulted to the name of the mpc file without the extension\n\n2) If a particular list is not specified (Source_Files, Header_Files, etc.):\n\n   all of the files in the directory will be added to the corresponding list\n   by extension\n\n3) If the custom type is automatic (both input and output) and custom files\n   (ex., idl files) exist in the directory and the custom files components\n   (ex., IDL_Files) are left defaulted (i.e. not listed) or the custom files\n   components are specified and none of the custom generated files are listed\n   in the corresponding lists:\n\n   the custom files are added to the custom files component list if they\n   weren't specified and all of the (would be) generated files will be added\n   to the front of the corresponding lists (source, inline and header lists)\n\n4) If files are listed in the Source_Files list and a corresponding header or\n   inline file exists:\n\n   the corresponding file will be added to the corresponding list (if it\n   isn't already there)\n\n5) If a sharedname is specified and staticname is not:\n\n   staticname is assigned the sharedname value (the same applies if\n   staticname is specified and sharedname is not)\n\n6) If exename is specified then the project target is considered an\n   executable.  If neither exename, sharedname or staticname are used and\n   any of the source files listed contains a language dependent \"main\", then\n   the project target is considered an executable, otherwise it is considered\n   a library.\n\n7) If pch_header is not specified and a header file matches *_pch.h:\n\n   it is assumed to be the precompiled header file (the same applies to\n   pch_source)\n\nProcessing Order\n----------------\n1) Project file is read\n2) Template input file is read\n3) Template file is read\n4) Output project is written\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpsigen%2Fmpc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpsigen%2Fmpc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpsigen%2Fmpc/lists"}