I'm integrating the WireGuardKit, according to its README file, I need to create an external build system target to build wireguard-go-bridge library.
In the external build system target's info tab. The documentation says I should use this location: ${BUILD_DIR%Build/*}SourcePackages/checkouts/wireguard-apple/Sources/WireGuardKitGo
The build for the external build system target failed. As the path can't be resolved.
If I change the path with a correct, absolute path, the build will succeed.
Can anyone tell me what's the meaning of this ${BUILD_DIR%Build/*}, looks firebase is also using this magic variable, see Firebase Crashlytics | Swift Package Manager (SPM) Run Script?
After some googling, I figured it out:
Quote SuperUser contributor Marek Rost's Post:
When the percent sign (%) is used in the pattern ${variable%substring}, it will return content of the variable with the shortest occurrence of substring deleted from the back of the variable.
This function supports wildcard patterns, that is why it accepts an asterisk (star) as a substitute for zero or more characters. It should be mentioned that this is Bash specific. Other Linux shells do not necessarily contain this function.
If you want to learn more about string manipulation in Bash, then I highly suggest reading the following page, Advanced Bash-Scripting Guide: Chapter 10. Manipulating Variables. Among many other handy functions, it explains what a double percent sign (%%) does, for example.
I forgot to mention that when it is used in the pattern $((variable%number)) or $((variable1%$variable2)), the percent sign (%) character will function as a modulo operator.
When the percent sign (%) is used in different contexts, it should be recognized as a regular character only.
So suppose ${BUILD_DIR} is
~/Library/Developer/Xcode/DerivedData/wgShowcase-dejirdnsktlwtagdrhljeefdnxvi/Build/Products
What ${BUILD_DIR%Build/*} mean is delete the shortest occurrence of substring Build/*(the star sign is a wildcard) from the back of ${BUILD_DIR} variable. In this case, the Build/Products will be removed. then we have the result:
~/Library/Developer/Xcode/DerivedData/wgShowcase-dejirdnsktlwtagdrhljeefdnxvi/
So since all the SPM packages used by this project checks out at a child directory at ~/Library/Developer/Xcode/DerivedData/wgShowcase-dejirdnsktlwtagdrhljeefdnxvi/, the final resolved path should be:
~/Library/Developer/Xcode/DerivedData/wgShowcase-dejirdnsktlwtagdrhljeefdnxvi/SourcePackages/checkouts/wireguard-apple/Sources/WireGuardKitGo
As for why the build is not succeed, I think it's a Xcode bug. I have reported a bug to apple. For anyone who is trying to build.
Use below as a workaround:
${BUILD_DIR}/../../SourcePackages/checkouts/wireguard-apple/Sources/WireGuardKitGo
Update: Here is the response from Apple regarding to this 'issue'
After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue:
The Directory field here is not evaluated as a bash variable, it’s evaluated as an Xcode build setting, which does not support bash operators such as %.
You would likely need to set the working directory to a known directory with a makefile, and then have that makefile use makefiles from the ultimate target directory.
We noticed that when we clone the repo it comes with macOS and iOS targets whose directories are set to $(PROJECT_DIR)/Sources/WireGuardKitGo, so we're wondering if the project owner has updated the project to fix this issue, but hasn’t updated the documentation.
In any event, this is behaving correctly.
Related
The title says it all, but for example, if the HEAD of a Git repository points to ref/heads/master on any well-used Git implementation for Windows, which of the following is the content of the file .git/HEAD ... oops, .git\HEAD:
ref: refs/heads/master, or
ref: refs\heads\master ?
Either way, I need to calculate the absolute path <git project>\.git\refs\heads\master, but I don't have Windows environment and I can't get to know which form is used! Answer is greatly appreciated.
Background: I'm modifying a Haskell library implementing a macro that embeds the Git revision hashes of Haskell projects into their source codes right on compilation (very nice for implementing --version option!). When we compile the program invocating that macro, git is called; however even before that, when a build tool is checking whether recompilation is required, we cannot call git and all that's done is simple file update check! Therefore, at the time of each compilation, we must compute and save the path of reference file at which HEAD is pointing, so that the reference file would be checked for update next time. The problem is that I would like to make the library cross-platform but that I don't know how to compute the path of a reference file on Windows, for I don't know the original form.
HEAD uses a reference name and not a path separator. Git always uses forward slashes in reference names, even on Windows. Backslashes are never allowed in a reference name on any platform, ever.
Since Windows will also allow forward slash path separators (unless you're using UNC paths), it's usually safe to just use forward slashes everywhere unless you know you have special needs.
Hopefully someone could help me here with following problem – tried to find a solution for this for weeks but unfortunately wasn’t able to find one.
I am using IzPack (recently updated to 5.1) as an installer for a software package. This package contains multiple executable files (bash scripts) which use variables inside. These variables are filled with values provided by the user during the installation process (user input panel).
The problem I have is that all these values get substituted in the bash-file if it is marked as “parsable” – otherwise (if not marked as “parsable”) the values are not substituted but it is not possible to access them during script execution. I have to access the values of these variables but it is no option for me to substitute them in the bash scripts because these files are not deleted after the installation is done and have to stay on the disk. In case of variable substitution all variables, also passwords, are substituted and could be seen by everybody, having read access to the file, in plaintext.
Has anyone got a solution or idea how this could be achieved using izPack? I also thought about encrypting the passwords – there exists a processor for it in izPack but unfortunately no documentation.
Thanks in advance
How about sanitizing or removing the files in question using the ProcessPanel?
This is typically run after the InstallPanel and before the installation is finished.
As suggested by https://www.visualstudio.com/en-us/docs/tfvc/share-your-code-in-tfvc-xcode I am putting my existing code to TFVC using git-tf. But my paths are deep. During check-in I am getting,
git-tf: TF205022: The following path contains more than the allowed 259 characters:
/Users/VeryLongPath
Even though the path length limitation is really annoying, the most effective and easy way still is spending some time tweaking your file/folder structure to make this work.
For example: instead of \xx\Build\Drop\ProjectName, just use \xx\Build\Drop (or \xx\Builds) since the project name is also in the build name.
For the long path issue in TFS, there had been a related uservoice and now completed. However, it's still a problem in some areas.
Fix 260 character file name length limitation
We’ve removed the limitation from the BCL for the basic file
manipulation functionality (CRUD). You can find more details here:
https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
Immo Landwerth Program Manager .NET
Also suggest you to take a look at this great blog-TFS Path Too Long problems for how to deal with the issue.
In short currently its the TFVC limitation, from https://www.visualstudio.com/en-us/docs/reference/naming-restrictions#version-control-paths
Must not contain more than 259 Unicode characters for a single folder or file name.
I've ran into a problem during the C/C++ build using Eclipse/CDT for a project containing many source files - during the linking phase a very long command line is created that is then passed to CreateProcess Windows API function. This command is in format of: {compiler} {flags} path/to/file1.o path/to/file2.o path/to/file3.o [...] and essentially contains all object files created during compilation and in my case is over 34K characters long.
Now historically this has already been looked at, but in my feeling the problem was only raised to a higher character limit. In particular, when looking here it is mentioned there was a problem with 8192 character limit, which seems to be the case when the command was directly passed to command line. The change which attempted to fix it was to use CreateProcess WINAPI function instead, which has a higher limitation of 32767 characters (limits depend on version of Windows used). In case of the project I'm working with, neither limit is high enough, as I've already reached over 34K characters for that particular command.
I've mentioned GNU ARM Elipse as this is what I'm working with, however this is a general issue with the CDT itself and it seems to also be a problem in other IDEs - for example I've read the same kind of reports from Netbeans users. Because I work with embedded systems and there are tools already integrated with Eclipse, moving to another IDE isn't an option.
As for the actual solution - the ideal situation to me would be to have the list of object files passed through a temporary file, as the character limitation is completely bypassed this way. So far I'm using CTD's makefile generator, as it is integrated with the IDE itself (flags, build exclusions etc.), however it isn't configurable in any way or at least none that I'm aware of that would solve my issue.
What are my options here? If it's necessary I might look into the makefile generator itself and modify it to output to file, however I'd rather avoid doing so if it's not the last possible option.
I'm using Maven to generate an archetype. I'm able to get the archetype to generate fine and the project template it generates works as expected. The only problem is in my shell scripts. Anything commented out in the script gets stripped leaving behind only commands. I've searched high and low and all I've been able to find was another user facing a similar issue with java comments. https://stackoverflow.com/questions/18797333/maven-archetype-generation-is-stripping-java-comments That question remains unanswered, so I figure I'll ask again. Does anyone know why Maven archetypes strip comments or how to prevent this from happening?
Using the #set command itself to set a #hash variable equal to "#" worked, allowing me to maintain shell comments in scripts generated by the archetype. This can get relatively ugly when using 80 # symbols in a row in a header, but that's another matter...
I also had a similar problem with hashes. On page http://johnjianfang.blogspot.com/2009/03/escape-properties-in-maven-archetypes.html I found answer.
Something like this works fine in my case:
#set($hash = '#')
${hash}
Output:
#
Maven uses Apache Velocity to perform substitutions/replacements when copying your archetype's template files to the project locations. The '#' character is used to begin directives, e.g. #set, in Velocity. My guess is that Velocity doesn't recognize your comment as a valid directive and silently deletes it during the replacement process.
Though I haven't verified this works - I would try escaping the comments with using a backslash (\) as defined in Velocity's user manual to solve the issue.