I've got a project structured thusly:
- proj/
- subproj1/
- stack.yaml
- subproj1.cabal
- ...
- subproj2/
- stack.yaml
- pkg1/
- ...
- pkg2/
- ...
- ...
And my subproj1/stack.yaml file contains this:
packages:
- .
- location: ../subproj2
subdirs:
- pkg1
- pkg2
extra-dep: true
I'm noticing inconsistent build behavior, when running "stack build" from within the subproj1/ directory. And I'm wondering if I have set up my project structure in an inherently unstable way. Would it, for instance, be more stable to use a single stack.yaml file, located in the proj/ directory?
Yes, unfortunately there are some known issues with this setup - https://github.com/commercialhaskell/stack/issues/3130 . Hopefully will be fixed at some point! One way to work around this is to set your STACK_YAML environment variable, so that stack invocations will ignore current directory.
Related
I want to use a github action matrix for different build types, but there's one case of the matrix that I'm not interested in supporting. How do I stop this case from running but still get the build to marked successfully.
In this particular case I want to build Windows and Ubuntu, 32bit and 64bit but I'm not interested in supporting 32bit on Ubuntu. So my matrix would be:
strategy:
fail-fast: false
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
My current solution is to stop each action running by adding an if expression:
- name: Build Native
if: ${{ ! (matrix.os == 'ubuntu-18.04' && matrix.platform == 'x86') }}
While this works okay, I feel there ought to be a more elegant way of solving this. Can anyone help make my yaml script more beautiful?
Perhaps the strategy.matrix.exclude directive is suitable?
From the documentation:
You can remove a specific configurations defined in the build matrix
using the exclude option. Using exclude removes a job defined by the
build matrix.
So in your case, probably something like this:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
exclude:
- os: ubuntu-latest
platform: x86
There are situations where one wants to include or exclude specific matrix coordinates so as not to run some of them, yet (stretching the question a bit) also still want the job to run for a couple of these coordinates, so as to track the evolution of it across commits, while not blocking the whole process.
In that situation, continue-on-error at the job level, combined with matrix include and exclude is very useful:
Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.
This is similar to GitLab CI's allow_failure, although at time of writing GitHub Actions UI only has two states (red failed and green passed) whereas GitLab introduces a third one (orange warning) in that case.
Here is a real-life workflow example:
jobs:
linux:
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
os:
- ubuntu-20.04
container:
- 'ruby:2.0'
- 'ruby:2.1'
- 'ruby:2.2'
- 'ruby:2.3'
- 'ruby:2.4'
- 'ruby:2.5'
- 'ruby:2.6'
- 'ruby:2.7'
- 'ruby:3.0'
- 'ruby:2.1-alpine'
- 'ruby:2.2-alpine'
- 'ruby:2.3-alpine'
- 'ruby:2.4-alpine'
- 'ruby:2.5-alpine'
- 'ruby:2.6-alpine'
- 'ruby:2.7-alpine'
- 'jruby:9.2-jdk'
experimental:
- false
include:
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2'
experimental: true
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2-alpine'
experimental: true
When using conda env export it is possible to remove the build information with --no-build:
...
dependencies:
- _libgcc_mutex=0.1=main
- attrs=19.3.0=py_0
- backcall=0.1.0=py37_0
- beautifulsoup4=4.8.2=py37_0
- biopython=1.76=py37h7b6447c_0
- blas=1.0=mkl
- bleach=3.1.0=py37_0
...
and with --no-build
dependencies:
- _libgcc_mutex=0.1
- attrs=19.3.0
- backcall=0.1.0
- beautifulsoup4=4.8.2
- biopython=1.76
- blas=1.0
- bleach=3.1.0
- bzip2=1.0.8
- ca-certificates=2020.1.1
Could you explain in detail what exactly is this build information? The compiler and its version? What else is in there?
The build information is a hash of the variant keys in the recipe. Quoting the docs:
The takeaway message is that hashes will appear when binary compatibility matters, but not when it doesn't.
and
As of conda-build 3.1.0, this hashing scheme has been simplified. A hash will be added if all of these are true for any dependency:
Package is an explicit dependency in build, host, or run deps.
Package has a matching entry in conda_build_config.yaml which is a pin to a specific version, not a lower bound.
That package is not ignored by ignore_version.
OR
Package uses {{ compiler() }} Jinja2 function.
The documentation is here: https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html#differentiating-packages-built-with-different-variants There's also a blog post (that I can't find now) with some more information.
In the steps of setting up CI builds on our gitlab server, I can't seem to find information on how to set up the detection of compiler warnings. Example build output:
[100%] Building CXX object somefile.cpp.o
/home/gitlab-runner/builds/XXXXXXX/0/group/project/src/somefile.cpp:14:2: warning: #warning ("This is a warning to test gitlab") [-Wcpp]
#warning("This is a warning to test gitlab")
^
However the build result is success instead of warning or something similar. Ideally the results wuold also be visible on the merge request on the feature (and block the merge if possible).
I can't imagine I'm the only one trying to achieve this, so I am probably looking in the wrong direction. The 'best' solution I found is to somehow manually parse the build output and generate a JUnit report.
How would I go about doing this without allowing the build job to fail, since I would like the job to fail when compiler errors occur.
Update
For anyone stumbling across this question later, and in lieu of a best practice, this is how I solved it:
stages:
- build
- check-warnings
shellinspector:
stage: build
script:
- cmake -Bcmake-build -S.
- make -C cmake-build > >(tee make.output) 2> >(tee make.error)
artifacts:
paths:
- make.output
- make.error
expire_in: 1 week
analyse build:
stage: check-warnings
script:
- "if [[ $(cat make.error | grep warning -i) ]]; then cat make.error; exit 1; fi"
allow_failure: true
This stores the build output errors in make.error in the first stage, the next stage then queries that file for warnings and fails that stage with allow_failure: true to create the passed with warning pipeline status I was looking for.
It seems that the solution to such need (e.g., see the issue "Add new CI state: has-warnings" https://gitlab.com/gitlab-org/gitlab-runner/issues/1224) has been to introduce the allow_failure option so that one job can be the compilation itself, which is not allowed to fail (if it does, then the pipeline fails) and another job can be the detection of such warnings which is allowed to fail (if one is found then the pipeline will not fail).
Also the possibility of defining warning regex in the .gitlab-ci.yml has been requested but it does not exist yet.
I want to create system restore points in my NSIS 2.46 installer. I googled around and found SysRestore plug-in is the best choice.
I downloaded the SysRestore.zip from http://nsis.sourceforge.net/SysRestore_plug-in, unzipped it and copied it to the installation folder of NSIS. But even the shipped example (\Examples\SysRestore\example.nsi) can't compile correctly.
The log is shown below:
MakeNSIS v2.46 - Copyright 1995-2009 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.
Processing config:
Processing plugin dlls: "C:\Program Files (x86)\NSIS\Plugins\*.dll"
- AdvSplash::show
- Banner::destroy
- Banner::getWindow
- Banner::show
- BgImage::AddImage
- BgImage::AddText
- BgImage::Clear
- BgImage::Destroy
- BgImage::Redraw
- BgImage::SetBg
- BgImage::SetReturn
- BgImage::Sound
- Dialer::AttemptConnect
- Dialer::AutodialHangup
- Dialer::AutodialOnline
- Dialer::AutodialUnattended
- Dialer::GetConnectedState
- InstallOptions::dialog
- InstallOptions::initDialog
- InstallOptions::show
- LangDLL::LangDialog
- Math::Script
- NSISdl::download
- NSISdl::download_quiet
- Splash::show
- StartMenu::Init
- StartMenu::Select
- StartMenu::Show
- System::Alloc
- System::Call
- System::Copy
- System::Free
- System::Get
- System::Int64Op
- System::Store
- TypeLib::GetLibVersion
- TypeLib::Register
- TypeLib::UnRegister
- UserInfo::GetAccountType
- UserInfo::GetName
- UserInfo::GetOriginalAccountType
- VPatch::GetFileCRC32
- VPatch::GetFileMD5
- VPatch::vpatchfile
- nsDialogs::Create
- nsDialogs::CreateControl
- nsDialogs::CreateItem
- nsDialogs::CreateTimer
- nsDialogs::GetUserData
- nsDialogs::KillTimer
- nsDialogs::OnBack
- nsDialogs::OnChange
- nsDialogs::OnClick
- nsDialogs::OnNotify
- nsDialogs::SelectFileDialog
- nsDialogs::SelectFolderDialog
- nsDialogs::SetRTL
- nsDialogs::SetUserData
- nsDialogs::Show
- nsExec::Exec
- nsExec::ExecToLog
- nsExec::ExecToStack
!define: "MUI_INSERT_NSISCONF"=""
Changing directory to: "C:\Users\Administrator\Downloads\SysRestore\Examples\SysRestore"
Processing script file: "C:\Users\Administrator\Downloads\SysRestore\Examples\SysRestore\example.nsi"
Name: "System Restore Example"
OutFile: "Example.exe"
InstallDir: "$PROGRAMFILES\$(^Name)\"
ShowInstDetails: Show
ShowUninstDetails: Show
Page: Directory
Page: InstFiles
UninstPage: UninstConfirm
UninstPage: InstFiles
Var: "Error"
Section: "install"
SetOverwrite: try
StrCpy $Error "0" () ()
DetailPrint: "Setting System Restore point..."
Invalid command: SysRestore::StartRestorePoint
Error in script "C:\Users\Administrator\Downloads\SysRestore\Examples\SysRestore\example.nsi" on line 20 -- aborting creation process
In my knowledge, a NSIS plug-in should provide a .nsh file to be included in the .nsi script. The include header will provide the definitions about the functions like SysRestore::StartRestorePoint. So the compiler won't complain about it.
But I didn't find a .nsh in the folder of SysRestore. What's wrong with this plug-in? Or there's something missing in my usage?
Thanks!
You can't just copy the folders from the extracted archive, since it uses a NSIS 3.x file structure for plugins. Copying the folders for documentation and examples is fine though.
When using NSIS 2.x, make sure that Plugins\x68-ansi\SysRestore.dll is copied to %PROGRAMFILES%\NSIS\Plugins.
Look at this compile time message, and the following lines:
Processing plugin dlls: "C:\Program Files (x86)\NSIS\Plugins\*.dll"
SysRestore::StartRestorePoint doesn't appear in the list of loaded plugins. Did you copy SysRestore.dll to the Plugins folder? If you just extracted it to a different folder, then you need to use !addplugindir and include that folder.
I have problem. I add new dialog in old project, and I have some error:
X:MEATFACTORYMaterialsMaterials.rc (22): error RC2135 : file not found: 0x19
X:MEATFACTORYMaterialsMaterials.rc (74): error RC2135 : file not found: 128
X:MEATFACTORYMaterialsMaterials.rc (1764): error RC2104 : undefined keyword or key name: IDC_LIST_RESULT
Error executing rc.exe.
What is it means?
codepage in file - win1251
what do me?
I need resolve this problem only for VC6.0
At all, the cause of this error was that in the process of adding resources VS6.0 then why (why ? This is not understood) has created another new file resourse.h in the expansion which was added two do not read Unicode characters. That is, were present in the directory two files resourse.h - and with different content. When I set up the conditions as compile / c 68001 - then picked up by a file with Unicode but not complete - and that caused a second group of errors. And if the file is compiled as ASCII - from the point of view of the file system at the studio had two files with the same name - and not one of them could not read ( of course). That is, if you get this error - check the file resource.h - and places without glitches such as in this case .
It is also (probably) this is due to the fact that VS works for me on virtualke to Linux - but from the point of view of the file system of Linux is nothing extraordinary - just two files with different names.