A lot of .nsh modules expect /D{NAME} or /D{name=value} style arguments passed to the makensis call to work properly. Can we get a new CPACK_NSIS_DEFINES variable that will allow a list of strings each then added as /D..... /D..... in the makensis call.
Just by curiosity, isn't this syntax c++17 and cmake should build in c++11?
Same as comment in !7227 (comment 1181894) (bug #21318 (closed)), I don't think the bom should be changed here and it may be a side effect of saving the file.
(I don't have any opinion on the other change of this MR, I'm not competent enough in NSIS to tell if it is good or not)
I've extended the original request that was only for the defines to all arguments according to https://documentation.help/CTRE-NSIS/Section3.1.html
Usage: cmake.exe -DCPACK_NSIS_EXECUTABLE_PRE_ARGUMENTS="V1;Dversion=2.2" -DCPACK_NSIS_EXECUTABLE_POST_ARGUMENTS="Dtest" ..
Fixes: #23446
Topic-rename: cpack-nsis-arguments-command-line
thank you for the report and the patch! Can you create a merge request with the fix?
if no more info is provided from @apthorpe or anyone who followed the first thread, I guess you can go with it and do a MR
If I understand correctly from a previous comment:
I'm not sure what repository's use case is here. I'd think you could infer type from url. commit seems to make branch redundant; branch only seems useful if you can't supply a commit ID. The attributes are all considered optional but aren't independent; maybe it's better to hold off implementing repository until there's a better understanding of how (if?) it's used in practice. As long as _cpack_nuget_variable_fallback_and_wrap_into_element() handles attributes, repository will be simple to implement later.
It seems it was more the usefulness of the tag that was questioned. Not sure there was a real issue with it? The corresponding diff is here
Hi, do you want to help adding this feature?
Looking at the code, it should be adding a new tag in nuspec.in and handling the 4 different variables in the CMake file (for example, _CPACK_NUGET_REQUIRELICENSEACCEPTANCE_TAG
) to create the line.
I'm not sure of this change? If it is the "BOM" change, it would be better to revert the change as it was added in c92b9623 to handle correctly Unicode
Hi, Are you interested to help adding this feature? There is a contribution guide: https://gitlab.kitware.com/cmake/cmake/-/blob/master/CONTRIBUTING.rst
I think adding a new CPACK_NSIS_EXECUTABLE_OPTIONS
variable and appending it in this call should do the job.
the function FreshCacheOn
called just above does the same?
@enmarantispam It seems the code can already generate grpc. Would it be enough?
In CPack NSIS Generator when using components, the DESCRIPTION field is ignored in the final installer.
The MUI_FUNCTION_DESCRIPTION_BEGIN/END block has to come after the sections in the .nsi
See, e.g., this link on Stackoverflow.
The CPACK_NSIS_INSTALLER_MUI_COMPONENTS should be removed from there:
;--------------------------------
; Define some macro setting for the gui
@CPACK_NSIS_INSTALLER_MUI_ICON_CODE@
@CPACK_NSIS_INSTALLER_ICON_CODE@
@CPACK_NSIS_INSTALLER_MUI_WELCOMEFINISH_CODE@
@CPACK_NSIS_INSTALLER_MUI_UNWELCOMEFINISH_CODE@
@CPACK_NSIS_INSTALLER_MUI_FINISHPAGE_RUN_CODE@
and moved to this place:
;--------------------------------
; Component sections
@CPACK_NSIS_COMPONENT_SECTIONS@
@CPACK_NSIS_INSTALLER_MUI_COMPONENTS_DESC@
;--------------------------------
I attached a MWE: test_nsis_components.zip
Run with something like: cmake -DCMAKE_BUILD_TYPE=Release .. && cmake --build . --config Release && cpack.exe . --config Release
I could only manually test the fix because the actual unit tests won't be able to help to know if the installer really displays the description when hovering the component or not.
Also, I didn't added any note as it is a "small" bug fix but I can add a release note if necessary.
Fixes: #23151
Topic-rename: cpack_nsis_no_description
No problem :).
MR = merge request -> I'm doing the change in the code and I'm asking reviewers to accept it to add it starting the next version.
When you have time, feel free to attach a MWE so I can double check it. I'll try to do one on my own but I haven't used yet components with NSIS so it would be better coming from someone who already uses them.
Hi, I can work on it if you can't do the MR. Do you have an example to test the case?
cmake -E cat <file1> <file2> <file3> ...
apparently stops concatenating files as soon as an empty one is encountered.
Minimal case:
echo aaa > a.txt
cmake -E touch b.txt
echo ccc > c.txt
I would expect the output of:
cmake -E cat a.txt b.txt c.txt
to be:
aaa
ccc
but since b.txt
is empty, the output is:
aaa
On the other hand, the output of:
cmake -E cat a.txt c.txt
is:
aaa
ccc
as expected.
Verified with CMake 3.21 on Windows and Linux. I'm not sure if this is the way cmake -E cat
is intended to work: type
on Windows and cat
on Linux process all files independently whether they are empty or not.
Johnny Jazeix (0b4a56e6) at 18 Sep 12:55
cmake: -E cat stops when an empty file is encountered