I am trying to get Rebol 3 to compile in Microsoft Visual Studio 2013, but so far I have been unsuccessful. I am using a Git repo for my source which does not come with a solution. I have tried creating a solution and manually importing all of the code files, but that does not work. I really do not know what I am doing, so any help would be appreciated.
Please clone my repository: https://github.com/zsx/r3
Once you have cloned the repository, checkout the "atronix" branch (you're probably on it when you first cloned it), and initialize & update the submodule:
git clone https://github.com/zsx/r3.git
cd r3
git submodule init
git submodule update
Open the ms vs solution file make/msvc/r3.sln
Edit:
The old branch "msvc" is merged to "atronix", so use this one instead.
Related
In Meson, subprojects can be defined using wrap-files. The manual shows an example of a wrap-git file:
[wrap-git]
url = https://github.com/libfoobar/libfoobar.git
revision = head
I've set-up a local test project that sets up a subproject like the example above. All works well and Meson pulls in the subproject's repository, builds it, and links it with the test project executable.
However, when I push a new change to the subproject repository, Meson fails to pull in these changes automatically even though revision = head is specified in the wrap-file. To be clear, I did not really expect this to work.
What does work is manually removing the subproject's source code and then letting Meson reconfigure the project. This clones the subproject repository and thus pulls in updates. But sadly this is a manual action...
My question: when tracking the head revision in a git wrap-file of a subproject, how to pull updates automatically?
This is expected behavior. As per reference doc:
Once a subproject has been fetched, Meson will not update it
automatically. For example if the wrap file tracks a git branch, it
won't pull latest commits.
To pull latest version of all your subprojects at once, just run the
command:
$ meson subprojects update
If only selected are needed, add names after command:
$ meson subprojects update libfoo libbar
(this is in short, more details in the link)
I was trying to cross compile glib for arm. It has a dependency on libffi, but found that a meson build for libffi was last updated 2 yrs back and there is a problem with what is available.
Therefore i had to define a wrap file to take the latest source of libffi.
My first idea was to use a wrap file as below -
[wrap-git]
directory=libffi
url=https://github.com/libffi/libffi
revision=head
p.s its the head revision that has the right source code for libffi. But it needed a meson revision and doesn't seem to take the head.
Therefore i went for the [wrap-file] option,
[wrap-file]
directory = libffi-3.3
source_url = https://github.com/libffi/libffi/releases/download/v3.3/libffi-3.3.tar.gz
source_filename = libffi-3.3.tar.gz
source_hash = 72fba7922703ddfa7a028d513ac15a85c8d54c8d67f55fa5a4802885dc652056
But still i get this error "Subproject exists but has no meson.build file" when doing a meson build.
This is the original wrap file that came alongwith glib.
[wrap-git]
directory=libffi
url=https://github.com/centricular/libffi.git
revision=meson
what is the easiest way to get a wrap file working.
As far I can see, someone forked project and added support for meson, named that branch meson, so revision is just a name of branch containing meson.build
Official project does not have support for meson.build. What is really happening is when you build your project that uses wrap git/file, that project is fetched/downloaded&unzip and it searches for meson.build to build that dependency for your project.
You have couple options:
Fork project and add support for meson (optionally: make PR to official project)
Install and use it as dependency
Use conan package manager to get your dependency, you can even integrate it with meson (https://conan.io/center/libffi/3.3/?user=&channel=)
The pipeline is triggered by new commits to a master branch and publishes the package
Currently, the version is set manually and I'de be happy to have it set automatically.
What I thought at first was adding the following tasks to the pipeline:
checkout $Build.SourceBranch
run version patch --force
git push
This works and the version is really incremented properly, the thing is, it triggers another run of the pipeline, which will increment again, which will.. you get the idea, endless loop.
Is there a better way for doing that?
I've added the same tasks as mentioned in the question with a small change.
Apparently there is a way to skip the pipeline triggering, see here
So the npm version task looks like this:
version patch -m "Bump version to %s [skip ci]" --force
which prevents the next build from being triggered.
TIP: remember to give the 'author' (Azure DevOps user) permissions to Bypass policies when pushing if any.
Don't use the files in the source repo to keep track of the current/next version. I don't think you can break the loop easily, if you do.
You might be able to get away with running npm --no-git-tag-version version to increment the package.json version inside the build agent without the commit, so that you don't have a change you would have to push back to the origin. It should just change package.json and leave it dirty.
Wait until after the build has succeeded. Use a custom script task to extract the version from package.json, then git reset --hard (there is no reason to keep anything that has changed on the build server). While this will undo the change in package.json, you can now create a tag on the head that contains that version, then do a git push origin {tag-name} which should not introduce a new commit on the origin which would then re-trigger your pipeline.
Actually, I don't think a pipeline will be triggered just because a tag was added, but I honestly haven't tested it. I'm pretty sure it won't.
Sequence of tasks in your pipeline:
[Given a source repo where you have made sure to set the major and minor versions in package.json to reflect the current state of the code according to the rules of Semantic Versioning, and leave the patch value always set to 0, and, if desired, using pre-* values to describe the quality of the major/minor value:]
(This is not really a task, but just describing the start of the execution:) The job starts. Automatically, the code is pulled from the source repo into the build agent.
Using a utility command-line task and code or script that you write, run git describe --tags to find the most recent tag with a tagname matching the pattern you use (see below). (I prefer this sequence over calling npm version from-git because npm will just use the latest tag, which might not be a version number, depending on how much control you have over the branch.) Use string or regular expression operations to extract the major, minor, patch, and whatever pre-* value you might have. This is the previous version that we'll use to compare with what's in the package.json file. Note that you may have to follow these instructions to run a git command. Save it to a pipeline variable.
Using a utility command-line task and code or script that you write, run npm version to get the current major/minor/pre version out of the package.json file and save it to a different pipeline variable. I'm using PowerShell Core, so my command would look something like this to create a "currentPackageVersion" pipeline variable:
& npm.cmd version | ConvertFrom-Json | Select-Object -ExpandProperty {name-of-your-package} | Set-Variable -Name 'packageVersion' | Write-Output "#vso[task.setvariable variable=currentPackageVersion]$packageVersion"
Using a utility command-line task and code or script that you write, compare the previous version's major, minor, and pre-* values to determine whether any of them have changed. Set a new pipeline variable to reflect whether it has changed or not. I'll use the name "restartVersionPatchNumber", which is true if the current major, minor, or pre-* values are different from the previous version's major, minor, or pre-* values.
The npm Task conditionally runs a custom command: npm --no-git-tag-version version patch, which updates package.json in the build agent but does not commit the change, leaving your Working Area modified (dirty) (which might cause issues on subsequent builds if you are using your own build agents instead of hosted agents). The condition expression of the Task uses a custom condition that evaluates to the variable that I just set in the previous step ("restartVersionPatchNumber"). Note that if this task does not run, it should just use the value of the version that is in the package.json file (the current version that is now in the "currentPackageVersion" pipeline variable).
Using a utility command-line task and code or script that you write, run npm version to extract the new version that the npm version command set. Save it to a new pipeline variable; I'll call it "newVersionNumber".
The regular build tasks run, producing artifacts and possibly publishing them
Using a utility command-line task, run git reset --hard. You'll need to do this even if you're using a hosted build agent, because of the next step.
Using a utility command-line task, create a variable from the saved version number ("newVersionNumber") that contains the value of the tag's tagname that you want to use. Use a distinctive patter, like "AzPipelineBuild-PipelineName-PackageVersion-1.0.0" but using your version instead of 1.0.0.
Using a utility command-line task, run git tag {*tagname*}. For PowerShell, the syntax would be & git.exe tag $env:newVersionNumber
Using a utility command-line task, run git push origin {*tagname*}
Profit
You could (and maybe should) combine the command-line steps. I'm really partial to the PowerShell task running PowerShellCore (pwsh) as you may have guessed.
The package that got created as an artifact of the job will have the updated version as it was created in the build, and it will match the tag that is now in your original source code repo.
Alternately, use an external source (an Azure Function, etc.) or a different (second) git repo or even another branch that isn't tied to your CI trigger in your project that you use just for tracking build numbers, then use token replacement tasks to set the version just before you start the build. I don't like this idea much, but it would prevent re-triggering a new build.
Also, you're hopefully building just one package with that repo. The next thing to do is to publish that package to your Azure Artifacts feed, or npmjs.org or wherever. Don't rely on having the version baked into the original source code; anything that depends on that package should be pulling it out of that feed you published it to, not relying on it being built earlier in the build steps with a new version number.
Here's my implementation in Powershell which is a complete step based on the accepted answer. Note that this also handles some of the git issues such as the detached head that comes with this type of approach.
steps:
- checkout: self
persistCredentials: true
.
.
.
- task: PowerShell#2
displayName: 'Bump the version'
inputs:
targetType: 'inline'
script: |
$BranchName = "$(Build.SourceBranch)" -replace "refs/heads/"
git checkout $BranchName
git config --global user.email "anymail#anycompany.com"
git config --global user.name "Your name"
npm version prerelease -m "Auto increment pre-release version to %s [skip ci]" --force
git push
After i cloned my group project from GitLab, i got a nullreferanceexception towhen i run the application with visual studio, but my groupmates can run it without any problems. So apparently it is not the project bug.
I tried to clone it and/or to download from git several times, still the same problems.
Does anyone know what might cause this problem?
Thanks.
Compare line-ending settings: https://help.github.com/articles/dealing-with-line-endings/.
Get your current configfile contents with: git config --global --edit from your commandline.
Testing any changes to my Xcode project has become an exercise in patience whenever I build. After all the source files have compiled, I get the following message in the activity window at the top of Xcode:
"Running 3 of 3 Custom Shell Scripts"
I have not added any of my own custom shell scripts but I am using quite a few dependencies via Cocoapods and I am using 2 frameworks for the build environment, Crashlytics and Tapstream. Crashlytics requires you add a run script in the build phases, other than that I don't know where the other ones are coming from and they appear to be the bottleneck in my build time.
Can anyone enlighten me as to what is going on and how i possibly speed it up?
I can't enlighten you but I can tell you how I stopped mine from running. This also happened after installing Cocoapods. In my main project's Target, under Build Phases, I noticed two entries entitled Check Pods Manifest.lock and another called Copy Pods Resources.
Under both there was an unchecked option Run script only when installing. I checked both and at least for now my projects build and run fine without running the scripts.
This is kind of a crappy answer because I can't really give you any more information, and it might not even work for your case, so hopefully someone comes along and enlightens us.
POSSIBLE EXTERNAL BUNDLE ISSUES
So I just had a frustrating experience debugging an issue where a pod installed library's NSLocalized strings file weren't working. Turns out it was because I checked the option mentioned above. Pods-resources.sh, which had the lines to install the bundle, wasn't running in debug mode. It was only running when installing - of course! Something to watch out for.
More info in this question:
NSLocalizedStringFromTable not working in CocoaPod dependency
To fix the slow "Copy pods resources" problem I figured out a solution to only copy the resources if they haven't been copied before.
For this purpose we have to patch the *-resources.sh files that are created by cocoapods such that the copy procedure only happens if a generated file in the target directory doesn't exist (it is created upon first copy). As long as this target directory exists and includes this autogenerated file, the copy resources phase is skipped. This saves me about 30 seconds in my project (of course depends on your project size). To accomplish this do the following:
Create a patch file called 'copy_pod_resources_once.patch' in your project root dir with the following contents:
5a6,13
> NONCE_FILE="${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/copyresources-done.nonce"
> if [ -f "$NONCE_FILE" ]; then
> echo "already copied resources"
> exit 0
> else
> touch "$NONCE_FILE"
> fi
>
In the Podfile for your project add the following post install hook:
post_install do |installer_representation|
system('find "./Pods/Target Support Files" -name "*-resources.sh" | xargs -I{} patch -p0 {} -i ./copy_pod_resources_once.patch')
<other post install stuff>
end
For me, it was Crashlytics. There were some outstanding changes, as Crashlytics does auto-updating of its files. I reset/removed them and rebuilt and got past it.
So the general answer may be to check any third party components and make sure they're working properly.
As Ramsel has said in this answer,
https://stackoverflow.com/a/21318086/1752988
I also went to Build Phases and cleared out all the possible links to PODs, after trying most of the other solutions and the three build issues shown regarding Pods were cleared out.
But then one file which was not list under the XCode Project navigator was missing, but they were in the Downloaded Git Zip folder! Obviously, I copied it and put into the XCode project and try running it runs cleanly! :)
I had a similar issue in my project (however not using Cocoapods). It ended up being an issue with an application external to Xcode (Spritebuilder) somehow holding onto a resource within my Xcode project when it crashed. I forced the non-xcode application to close and now the issue is gone
Check your project folder name have any space.Because space creates problem in directory path like "SRCROOT".I removed spaces and project run fine.
I've found that this happens to me frequently. Exact cause unknown, but appears to be switching between git branches that have differences in what pods are being used. In my case simply touching the Pods-xxx-Resources.sh shell script file causes it to speed back up.
Probably not going to work for you, but cleaning the project fixed it for me (Product -> Clean)