Navigation: Templates > Template Language Reference > Complete Alpha Listing >====== #PROJECT (add file to project)  ====== |    |
#PROJECT( module )
| #PROJECT | Includes a source or object code library, or Project file, in the application's Project file. |
| module | A string constant which names a source (.CLW if Clarion is the target language), object (.OBJ), library (.LIB) file containing procedures required by the procedure Template. This may also name a Project (.PRJ) file to be called by the application's Project. The type of file being imported is determined by the file extension. You can also use this to add any valid project resource (icons, images, etc.) |
The #PROJECT statement specifies a source or object code library, or Project file, which is required to be in the application for the correct functioning of procedures created by the procedure Template.
#PROJECT provides a direct method of communicating module information to the Application Generator and Project system. It alerts the Application Generator to the required presence of the module for compiling and/or linking the application. Therefore, the application's Project file (generated by the Application Generator) automatically includes the module for making, compiling, and/or linking.
If multiple instances of the same #PROJECT statement are referenced by procedures created in the application, only the first is used. This would occur when multiple procedure Templates require the same module, or multiple application procedures are created from the same procedure Template.
#PROJECT allows a developer to automate the installation of third-party libraries and Templates to other developer's computers. This ensures that the application's Project is generated correctly.
#PROJECT for a Project (.PRJ) file provides the ability to create a hierarchy of Projects on large development projects. Where multiple libraries are being linked into a package, this allows you to ensure “make dependencies” are met for all libraries referenced in a particular project.
Extended library support for #PROJECT
Extended library support for the Clarion Win32/Clarion.NET project system is also available using the following format:
#PROJECT('BuildAction(FileName), <;CopyToOutputDirectory=CopyAction>')
where:
| BuildAction | Can be one of the following:projectreference, reference, include, compile, none, remove, library or filedriverprojectreference - file is a reference to another project (appears in the Referenced Projects list)reference ' same as projectreferenceinclude - file is an included project file (appears in the Projects to include list)compile - the file is added to the list of files to be compilednone - the file is added to the project with no associated compile or link actionremove - removes the file from the project (if the file doesn't exist no error is reported)library - the file is added to the project libraries node(appears in the Libraries, Objects and Resource Files list)filedriver - file is added to project file drivers node |
| FileName | Any file accessible via the redirection system |
| CopyAction | Used with optional CopyToOutputDirectory parameter.Can be one of these values; Never, Always, PreserveNewest. Only valid when BuildAction is set to library or none. |
Based on the combination of settings above, you can now specify if a library needs to be rebuilt, and if and how the library gets copied to the designated Output Path set by the target project.
When using the extended library support, you should programmatically set conditions when switching link modes to include or exclude your DLLs. See the example below.
Examples:
| #AT(%CustomGlobalDeclarations) |
| #PROJECT('Party3.LIB') |
| #ENDAT |
| #AT(%CustomGlobalDeclarations) |
| #PROJECT('Library(mylocalLib.LIB),CopyToOutputDirectory=Always') |
| !cause the library to be linked into the project and the matching dll copied to the !destination folder |
| #ENDAT |
| #AT(%CustomGlobalDeclarations) |
| #PROJECT('None(mylocalLib.Dll),CopyToOutputDirectory=Always') |
| !just copy the dll (useful when a dll is not directly used by a project, but is needed by !another dll |
| #ENDAT |
Adding Pre and Post Build Events using #PROJECT
You can now add pre and post build events to your projects using the #PROJECT template statement.
Syntax
#PROJECT('PreBuild|PostBuild(action)<;,Configuration=ConfigurationValue><;,IgnoreExitCode>')
| Action | The command to execute. This can include the project properties. Reference the Microsoft documentation on MSBuild for detailed information on using properties and items in your commands. | ||
| ConfigurationValue | Debug | Release | any user created configuration. Setting the Configuration attribute will limit the build event to run only when that configuration is active. |
| IgnoreExitCode | Forces the project to continue even if there are errors in the command. |
Implementation Notes
Normally the project will stop if your command causes errors. Setting the IgnoreExitCode attribute will mean the project will continue even if there are errors in the command.
You can generate multiple commands. The order they are executed in is based on the Configuration. All commands with a configuration will be executed together. The order within a configuration group is the order of the #PROJECT statements. However, the order that the configuration groups is executed is undefined.
For example, given the following PROJECT statements:
#PROJECT('PostBuild(md release),Configuration=Release,IgnoreExitCode')
#PROJECT('PostBuild(md debug),Configuration=Debug,IgnoreExitCode')
#PROJECT('PostBuild(copy “$(TargetPath)” $(Configuration))')
'you cannot expect that the copy command will execute after the md command.
To make sure the md is executed before copy you need to do:
#PROJECT('PostBuild(md $(Configuration))')
#PROJECT('PostBuild(copy “$(TargetPath)” $(Configuration))')
Or
#PROJECT('PostBuild(md release),Configuration=Release,IgnoreExitCode')
#PROJECT('PostBuild(md debug),Configuration=Debug,IgnoreExitCode')
#PROJECT('PostBuild(copy “$(TargetPath)” Debug)',Configuration=Debug)
#PROJECT('PostBuild(copy “$(TargetPath)” Release)',Configuration=Release)
The support for multiple pre and post build events is dependent on there being a pre or post build event in the project. If the user does not have one, the project will be modified to add a call to echo.
Post Build projects run based on the setting for “Run the post-build” event in the project properties. This property cannot be set via the templates. If you require your post build event to run under specific conditions, you will need to get the users of your templates to manually set this. Note that this is a global setting and applies to all post build events, regardless of which template generated them or if they are a user specified post build event. As such it is not advised to make your post build events dependant on how the project was run.
See also: Common Build Properties