For example:
As far as i know what is happening here is that jcapimin.c's AdditionalIncludeDirectories metadata property is being set so that it can be referenced later with the %(AdditionalIncludeDirectories) macro in the compilers command line and wherever else you want.
So what I don't understand is why when something down the line retrieves this information using the %(AdditionalIncludeDirectories) macro the information retrieved needs to have %(AdditionalIncludeDirectories) stuck on the end of it
Values of variables (properties, items, metadata, ...) are not automatically inherited in MsBuild, but instead new declarations of the same name override the previous value. So if the %(AdditionalIncludeDirectories) is not appended the new value of AdditionalIncludeDirectories would be just the ....\jpeg;....\jpeg\simd part and the compiler wouldn't be able to find standard library headers etc.
The property pages like you show are just a user interface on top of msbuild, which is easy to check if you open the project file in a text editor so here's a fictive sample of what happens in MsBuild:
<!--Somewhere in the msbuild files with compiler options-->
<ItemGroup>
<AdditionalIncludeDirectories Include="$(VCInstallPath)\include"/>
</ItemGroup>
The code in the above file is eventually included in your project file, and now you want to add directories to the compiler's include search path. Suppose you'd write
<ItemGroup>
<AdditionalIncludeDirectories Include="..\jpeg"/>
</ItemGroup>
then the new value of AdditionalIncludeDirectories is just ..\jpeg. Which is why we use
<ItemGroup>
<AdditionalIncludeDirectories Include="..\jpeg;%(AdditionalIncludeDirectories)"/>
</ItemGroup>
instead so the value is expanded to ..\jpeg;$(VCInstallPath)\include.
Unrelated remark: usually you shouldn't be declaring include directories per file like that; suppose there's a second file which also needs that jpeg include path, you'd have to repeat yourself and write the same thing again. Repeating yourself in programming is nearly always wrong. Declaring the include path on the project level would be a good start. If you also don't want to repeat the same path across projects, look into using property sheets.
Related
I am trying to perform a web.config transform in Visual Studio 2022 by modifying the web.Debug.config file.
Changing attributes on elements, removing elements and attributes, etc. is all very straightforward. But I've a read through this document and I've done some Google searching, and I cannot figure out a way to replace part of a path string in my web.config file.
Given that I have lots of NLog target elements is there an easy way to replace the root path in the fileName and archiveFileName attributes for each?
Here is where I am coming from:
<target xsi:type="File" name="seedDataLogFile"
fileName="C:/ProductionPath/Logs/seedDataCurrent.json"
archiveFileName="C:/ProductionPath/Logs/SeedDataArchive/{#}.json"
archiveEvery="Day" archiveNumbering="Date" archiveDateFormat="yyyy-MM-dd" maxArchiveFiles="60"
concurrentWrites="true" keepFileOpen="false">
And here is where I want to go:
<target xsi:type="File" name="seedDataLogFile"
fileName="D:/DevelopmentPath/Logs/seedDataCurrent.json"
archiveFileName="D:/DevelopmentPath/Logs/SeedDataArchive/{#}.json"
archiveEvery="Day" archiveNumbering="Date" archiveDateFormat="yyyy-MM-dd" maxArchiveFiles="60"
concurrentWrites="true" keepFileOpen="false">
Thanks for your help.
Been trying to set up configuration-specific variants of resource .resw files in my project, so I could have have different resource string values in Debug and in Release (and in other configurations).
There are standard facilities in VS to have files conditionally included or excluded from build depending on selected Configuration. I have set up file properties to be Content=Yes and Excluded From Build=No for a file that must be included in a configuration, and the other way around for the other file.
The variants appear as expected in the IDE - only one matching current configuration is active, and another one is shown with Content=False in the Properties view, and with a red icon in the files list. The vcxproj also contains correct PRIResource nodes for .resw files with DeploymentContent and ExcludedFromBuild set:
<ItemGroup>
<PRIResource Include="Debug\Strings.resw">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">false</ExcludedFromBuild>
<DeploymentContent Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</DeploymentContent>
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|ARM64'">false</ExcludedFromBuild>
<DeploymentContent...
Building this project however fails with a message
error PRI277: 0xdef00532 - Conflicting values for resource 'resw
name/resource name'
Examining intermediate files reveals that both .resw variants are listed in resources.resfiles that is then fed into MakePri.exe . The ExcludedFromBuild setting appears to be ignored.
How would I get this to work? Is there a special way to control the inclusion of resw files? Maybe a different approach to having string variants altogether?
There are apparently "qualifiers" for organizing resource variants, and a naming scheme (https://learn.microsoft.com/en-us/windows/uwp/app-resources/tailor-resources-lang-scale-contrast). There is even a "Configuration" qualifier, though it is not entirely clear which configuration that is, and where at run time I am supposed to take an identifier to select a resource variant I want.
Adding this as an answer for the sake of completeness, as this is relevant and might even be useful to someone. But I am not happy with project configuration concerns being displaced to runtime, with unneeded and possibly sensitive values being added to the package. So I decided to force-emulate ExcludedFromBuild and am picking and copying the single .resw variant I need into build via a Custom Build Step. Shout out to whoever is responsible for this awkward mess at Microsoft.
I am looking for a way to separate the repetitive html codes from web pages, and for this I am planning to use the macro functionality. The problem here is for every macro I need to put this macro in a file, or put some of them in a file and include this in the template file.
What I need is to include once just the directory name something like
<#import "/tags/widgetDirectory" as widgets />
here the /tags/widgetDirectory is a directory , and every files here can be seen as a macro defined.
when I need to insert a code part from a file from this directory lets say slide.ftl I will just use
<#widgets.slider />
the system will check for slider.ftl in the /tags/widgetDirectory directory . here the slider.ftl can have <#macro> as first and as last line , or these can transparently added and system can load it as a macro
this will easy my designer work.
Maybe there is better way for doing this kind of widgets/components based web design ?
best regards,
This feature (importing directories) is something that's planned for FM actually... but it won't happen anytime soon. But I guess it can be solved fairly well with a hack right now. Instead of #import, use your own TemplateMethodModelEx, that you could use like <#assign widgets = importDirectory('/tags/widgetDirectory') >. This will return a TemplateHashModel that's also implemented by you and is bound to the directory path. When an item of that hash is get, it uses Environment.getCurrentEnvironment().include. The included file is expected to create a macro with name __main or something. So then you get that variable with Environment.getCurrentNamespace().get("__main") and return it as the result of the hash lookup. Of course this hash should also maintain a cache, so that if the same item is get twice, it wont include the template for the second time, just return the macro extracted earlier. This can be developer further, so that if the include file didn't define __main, then it's supposed that it prints directly to the output, and so it will be included again, when the "tag" is called again.
Ok, so, I've got a relatively complex project template hierarchy that defines code style related macros and variables (curlies on same or new line, indentation, etc). My code style template will probably give more context
Works great when generating a project.
However, I'm not seeing a clear path to reusing these macros/variables when generating new files after the project has been built. Findings so far:
macros and variables defined at the project level are not substituted when referenced in a file template
popup option definitions in file templates do not seem to support complex definitions (e.g. defining a macro when the drop down is in a given state)
project variables do appear to become defaults for options of the same name in the file template wizard
file templates don't appear to be able to define other templates as ancestors
Any ideas?
Enter the following line:
defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions '{ "ORGANIZATIONNAME" = "Your Company Name" ; }'
into a Terminal window, replacing "Your Company Name" with whatever you choose.
You can also open the file at ~/Library/Preferences/com.apple.Xcode in "Property List Editor" and insert your company name as a string value for the key "ORGANIZATIONNAME" under the dictionary "PBXCustomTemplateMacroDefinitions". You may need to create "PBXCustomTemplateMacroDefinitions" at the top level if it doesn't already exist.
I want to create a fragment file that will only contain a CustomTable in the file. This is easy enough, but I do not know how to link/include it back into the main product.wxs file.
The fragment file is in the same project as the product file, and I have also tried adding an include tag for the file without success, and even putting the custom table into a WiX include file.
Is there a way to do this? Or is it going to have to live in the product file?
The WiX toolset compiles and links in a similar manner to the C/C++ compiler. The linker starts at the "main" entry point (Product element, in your case) then follows the references from there, which in turn follows references from there until all are resolved.
Part of your question is missing but based on the title I'm going to guess that you want a CustomTable element. Typically that CustomTable is processed by a CustomAction. There are a couple good ways to reference a CustomAction.
I would not use an include file.
You could try using EnsureTable if you'd like to make sure the table is created whether or not there is data in it. If you'd like to separate the custom table's schema definition from the data I believe you can just define them in separate fragments and reference the schema definition from the data definition fragment by opening with <CustomTable Id="your table name"> and defining the rows of data within it.
In general Wix won't pull fragments into the main authoring unless they contain elements that are referred to somewhere and since there is currently no such thing as CustomTableRef you may opt to use other elements such as an empty PayloadGroup or ComponentGroup that you can refer to (using a PayloadGroupRef or ComponentGroupRef respectively) from your main Bundle, Product or Module element as the case may be.