Now that the regression, introduced with the new Qt build system in 5.8 is resolved, how do specify external dependencies when building Qt?
Are we back to the old (bad) syntax that was removed in 5.8? Or is there a new way to do it?
From configure -help:
Each uppercased library name (obtainable with -list-libraries) supports the
suffixes _INCDIR, _LIBDIR, _PREFIX (INCDIR=PREFIX/include, LIBDIR=PREFIX/lib),
_LIBS, and - on Windows and Darwin - _LIBS_DEBUG and _LIBS_RELEASE. E.g.,
ICU_PREFIX=/opt/icu42 ICU_LIBS="-licui18n -licuuc -licudata".
Thus:
configure -list-libraries to get the list of configurable libraries.
For each FOO from the above, provide:
FOO_PREFIX or both FOO_LIBDIR and FOO_INCDIR,
FOO_LIBS if not empty,
optionally FOO_LIBS_DEBUG and FOO_LIBS_RELEASE if there's a difference between the two variants (not optional if FOO_LIBS is empty).
E.g., to set up MYSQL, assuming configure -list-libraries includes MYSQL:
configure \
MYSQL_INCDIR=E:\msys64\mingw64\include\mariadb \
MYSQL_LIBDIR=E:\msys64\mingw64\lib \
MYSQL_LIBS="-l mysqlclient"
Related
Running the .NET Core Pack task, how do I get the outputted NuGet package version to auto-increment itself?
So, for example, if my current version is 1.0.0, then the next time I call the Pack task, I would like to see 1.0.1.
I'm using environment build variables with Build.BuildNumber and getting outputs at the moment of e.g. 20180913-.2.0, etc. I would like to establish to a more traditional versioning system.
From the docs, the variable Rev:.r is the daily build revision count. The accepted "solution" would lead to one day finishing having a version of 1.0.12, then the next day it will be 1.0.1.
If you want a simple incremental and unique semver, use 1.0.$(BuildID).
$(BuildID) is an internal immutable counter for your builds, and thus far cleaner than $(BuildNumber).
BuildID will always be incrementing - no reset.
Thus after a minor bump, you'd end up having say 1.2.123 becoming 1.3.124.
If you want to perform this task well, this can be done using npm version or similar, such as pubspec_version for Dart or Flutter builds.
- script: npm version $RELEASE_TYPE
where $RELEASE_TYPE is a variable you can set based on build (ie: CI, PR etc), having a value of major, minor, patch, prerelease etc.
- script: npm version $RELEASE_TYPE
condition: startsWith(variables['build.sourceBranch'], 'refs/head/release/')
env:
releaseType: minor
Update: Bump Repo Version and Use In Build (using npm)
To have the repo version update, I ended up including npm version as a DevDependency, with it's precommit hook to bump the project version on any commit.
This technique can be applied to other project types, placing them in a subfolder - although can lead to complications with server OS requirements.
To use this version in your build, add this bash script task, which gets and exports the version as a task variable:
v=`node -p "const p = require('./package.json'); p.version;"`
echo "##vso[task.setvariable variable=packageVersion]$v"
.Net Core Task only version
Unfortunately, no repo-bump.
Workaround 1:
jobs:
- job: versionJob #reads version number from the source file
steps:
- powershell: |
$fv = Get-Content versionFile
Write-Host ("##vso[task.setvariable variable=versionFromFile;isOutput=true]$fv")
displayName: 'version from file'
name: setVersionStep
- job: buildJob # consumes version number, calculates incremental number and set version using assemblyinfo.cs
dependsOn: versionJob
variables:
versionFromFile: $[ dependencies.versionJob.outputs['setVersionStep.versionFromFile'] ] # please note that spaces required between $[ and dependencies
buildIncrementalNumber: $[ counter(dependencies.versionJob.outputs['setVersionStep.versionFromFile'],1) ] #can't use $versionFromFile here
steps:
- powershell: |
Write-Host ($env:versionFromFile)
Write-Host ($env:versionFromFile + '.' + $env:buildIncrementalNumber)
displayName: 'version from file output'
Workaround 2:
This post describes a couple of others, using version-prefix and automatically applying the BuildNumber as a version-suffix.
I may have figured it out. For anyone tearing their hair out, try this:
Pack Task:
Automatic Package Versioning: Use an environment variable
Environment variable: Build.BuildNumber
Then, up in the top menu where you have Tasks, Variables, Triggers, Options, click Options and set:
Build number format: 1.0$(Rev:.r)
Save and queue. This will produce e.g. 1.0.1.
(Please Correct me if I am wrong, or if this does not work long-term.)
If you're just looking to bump the major, minor or revision version number, using counter operator in a variable is a simple and elegant approach. It will automatically add one to the current value.
Here's what I use:
variables:
major: '1'
minor: '0'
revision: $[counter(variables['minor'], 1)] #this will get reset when minor gets bumped. The number after Counter is the seed number (in my case, I started at 1).
app_version: '$(major).$(minor).$(revision)'
If you would like to see a real-world 4-job pipeline that uses this, I have one here https://github.com/LanceMcCarthy/DevReachCompanion/blob/master/azure-pipelines.yml
For me it's enough to set Build number format on Options tab to
$(date:yyyy).$(date:MMdd)$(rev:.r)
and add next build argument:
/p:Version=1.$(Build.BuildNumber) /p:AssemblyVersion=1.$(Build.BuildNumber)
In this case we manage major version manually, but minor version and build number will be set automatically. Easy to understand what version you have deployed.
I am using the ado pipeline and a yaml build. What I've done is utilized the pipeline variables, a counter function, and an inline powershell function to create the version number. It auto-increments and has made the entire build process nice.
Another SO Post about something similar
I'm moving from Jenkins to using using Concourse CI to run my Sauce labs e2e tests. Sauce labs groups tests together that have the same build number string:
name: 'Chrome XS',
browserName: 'chrome',
tunnelIdentifier: process.env.TUNNEL_IDENTIFIER,
build: process.env.JENKINS_BUILD_NUMBER,
platform: 'Windows 10',
shardTestFiles: true,
maxInstances: 20,
How can I pass the build number to my script using an environment variable as shown above. The Concourse GUI uses name #number. Is there any way to retrieve this. I tried printing all the environment variables in the docker container but it's not set by default.
Metadata like the build number/ID are intentionally not provided to tasks. See https://concourse-ci.org/implementing-resources.html#resource-metadata
This sounds like potentially a use case for a Sauce Labs resource?
In Concourse, build metadata is only available for resources, not tasks.
An example on using build metadata with resources is to include it as part of build results notification emails. The following blog entry contains more information about it:
http://lmpsilva.typepad.com/cilounge/2016/10/how-to-insert-build-metadata-into-user-notifications-in-concourse.html
If you really want to use build number for versioning, you could try to create your own Concourse resource that would return the version number, however, I would use your code commit number instead. Another alternative would be to use the Semver resource in Concourse: https://github.com/concourse/semver-resource
We're switching from one to two Zope instances for our productoin Plone deployment. I have the following buildout structure defined:
buildout.cfg
[buildout]
extends = app.cfg
... some environment specific stuff
app.cfg
[buildout]
extends = base.cfg
parts =
zope2
productdistros
instance1
instance2
zopepy
supervisor
[instance1]
<= instance
http-address = 18081
[instance2]
<= instance
http-address = 18082
base.cg
[buildout]
parts =
zope2
productdistros
instance
zopepy
... bulk of buildout configuration suitable for both server and development
Testing this I'd expect this buildout configuration to result in the existing instance part to be deleted and replaced with instance1 and instance2. However the instance part is not deleted - it can still be found in bin and parts directory.
[zopetest#dev home]$ bin/buildout
Updating zope2.
Updating fake eggs
Updating productdistros.
Updating instance1.
Updating instance2.
Updating instance.
Updating zopepy.
Updating supervisor.
I have a very similar set-up on a different zope instance that was configured this way from the start and it has no "instance" part.
We're running zc.buildout 1.4.4 with Python 2.4.6 building Plone 3.3.6.
I've tried the following with no change:
* upgrading to buildout 1.5.2
* removing the parts assignment from base.cfg
This is a "feature" of plone.recipe.zope2instance. Traditionally the recipe has avoided removal of the instances and scripts it creates for running plone (for whatever reason: either poor design or deliberate decision, I am not sure).
For whatever it is worth, as of version 4.2.0 there is support for generating non-plone scripts (similar to zc.recipe.egg) and those scripts are managed properly. See:
https://github.com/plone/plone.recipe.zope2instance/blob/master/src/plone/recipe/zope2instance/init.py#L119
for all the gory details. (I believe the "feature" is that the install method does not return a tuple, unless you are using scripts in which case a tuple containing the scripts is returned.)
This was in fact due to the zc.buildout automatic part selection feature
When a section with a recipe is referred to, either through variable substitution or by an initializing recipe, the section is treated as a part and added to the part list before the referencing part
I had the following section
[zopepy]
# For more information on this step and configuration options see:
# http://pypi.python.org/pypi/zc.recipe.egg
recipe = zc.recipe.egg
eggs = ${instance:eggs}
As it referenced the “instance” section “instance” was included in the list of parts.
To fix I changed it to copy-paste the eggs value of instance
eggs =
Plone
${buildout:eggs}
and then ran bin/buildout
I have been trying to get clang's analysis tool working, but I am not sure how to overcome a particular error when I run it. I have installed X-Code 4.0 and iOS 5 the output I get is:
Generating class dependency graph.
Launching /Users//Desktop/HomeWork2/tools/AnalysisTool.app/Contents/Resources/llvm/utils/scan-build with arguments: (
"-o",
"/Users/<homedir>/Development/myApp/Static analysis/results",
"-v",
"--status-bugs",
"-checker-cfref",
"-warn-dead-stores",
"-warn-objc-methodsigs",
"-warn-objc-missing-dealloc",
"-warn-objc-unused-ivars",
"-analysistool-checker-access-control",
"-analysistool-checker-coersions",
"-analysistool-checker-cyclomatic-complexity",
"-analysistool-checker-conditional-logical-complexity",
"-analysistool-checker-conditional-nesting-depth",
"-analysistool-checker-loop-nesting-depth",
"-analysistool-checker-dealloc-safety",
"-analysistool-checker-declaration-conventions",
"-analysistool-checker-discouraged-method-calls",
"-analysistool-checker-error-handling",
"-analysistool-checker-extra-parentheses",
"-analysistool-checker-finalize",
"-analysistool-checker-format-strings",
"-analysistool-checker-kvo",
"-analysistool-checker-memory-management",
"-analysistool-checker-naming-conventions",
"-analysistool-checker-shadow",
"-analysistool-checker-unused-ivars",
"--use-cc=/Developer/usr/bin/llvm-gcc-4.2",
"--use-c++=/Developer/usr/bin/llvm-g++-4.2",
"-generate-class-dependency-graph",
xcodebuild,
"CONFIGURATION_BUILD_DIR=/Users/<homedir>/Development/myApp/Static analysis/build",
"CONFIGURATION_TEMP_DIR=/Users/<homedir>/Development/myApp/Static analysis/build",
"-configuration",
Debug,
clean,
build
).
scan-build: Emitting reports for this run to '/Users//Development/AMMO_SVN_Projects/MobXpo/branches/MobXpo_v12/Static analysis/results/2011-06-30-8'.
scan-build: 'clang-cc' executable not found in '/Users//Desktop/SWEN_646/HW2/tools/AnalysisTool.app/Contents/Resources/llvm/utils/libexec'.
scan-build: Using 'clang-cc' from path.
xcodebuild: error: invalid option '-nodistribute'
Usage: xcodebuild [-project ] [[-target ]...|-alltargets] [-configuration ] [-arch ]... [-sdk [|]] [=]... []...
xcodebuild -workspace -scheme [-configuration ] [-arch ]... [-sdk [|]] [=]... []...
xcodebuild -version [-sdk [|] [] ]
xcodebuild -list [[-project ]|[-workspace ]]
xcodebuild -showsdks
Options:
-usage print full usage
-verbose provide additional status output
-project NAME build the project NAME
-target NAME build the target NAME
-alltargets build all targets
-workspace NAME build the workspace NAME
-scheme NAME build the scheme NAME
-configuration NAME use the build configuration NAME for building each target
-xcconfig PATH apply the build settings defined in the file at PATH as overrides
-arch ARCH build each target for the architecture ARCH; this will override architectures defined in the project
-sdk SDK use SDK as the name or path of the base SDK when building the project
-parallelizeTargets build independent targets in parallel
-jobs NUMBER specify the maximum number of concurrent build operations
-showsdks display a compact list of the installed SDKs
-list lists the targets and configurations in a project, or the schemes in a workspace
-find BINARY display the full path to BINARY in the provided SDK
-version display the version of Xcode; with -sdk will display info about one or all installed SDKs
I have researched the internet but I have found nothing to help my specific problem. I think what i need to do is edit the clang tool to not include the "nodistribute" option, but im not sure if there is another way or where to get the source code to do so. Thanks in advance for any help.
I found a way around this after a lot of looking for an answer I decided to see if I could modify the line of code that was including the -nodistribute option. So I used grep to find the line of code in the .app bundle and then opened it in vi. I added a comment # to the line and bingo, off to the races.
The file, relative to the app bundle root is found at: ./Resources/llvm/utils/scan-build
I am trying to find a tool that will extract the module version information (a part of the module record) fron an Xserver module. For example, in the Xorg logs I can see the following information for the librecord module in my Xorg.0.log file...
[ 39.892] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[ 39.905] (II) Module record: vendor="X.Org Foundation"
[ 39.905] compiled for 1.9.0, module version = 1.13.0
[ 39.905] Module class: X.Org Server Extension
[ 39.905] ABI class: X.Org Server Extension, version 4.0
Is there a tools that would allow me to easily extract the aforementioned information. Sometimes you can use modinfo on the module and that will have version information, but that does not always work. The only consistent way I know of now is to parse the xorg log file. Thanks.
Yes, there is and you can also try to write a small one.
http://gitorious.org/xdriverprobe
The problem is that xdriverprobe won't compile on newer servers since I didn't update it to the newest ABIs. Also, xdriverprobe is only used for video drivers, but it can be adapted to be used on other modules. The main source code file (xdriverprobe.c) has less than 500 lines, so you can easily learn by reading it.
It works in Ubuntu 11.10... ./xdriverprobe -o moduledata gives the information you want.
Look at its source code. It does:
dlopen() the module
find a symbol called modulenameModuleData (if your module is called modulename)
that symbol is a XF86ModuleData* See /usr/include/xorg/xf86Module.h
check its member named vers
Spend a few hours and you'll be able to write a very tiny code that does what you want.
More information: http://www.xfree86.org/current/DESIGN17.html#65 (very old document, but most of what's written there is still true today). If you're not happy with that document, you have to read the Xorg source code.
Happy hacking!