InnoSetup has the ignoreversion flag for items in the [Files] section to specify that the file should be copied regardless of its version information. This is kind of the default that I would expect from a setup most of the time, yet it is not the default behaviour if it is not set. So I see this flag set in most setups for every file item, executables and non-executables alike.
I'm wondering what the file types are for which this flag makes any difference? Obviously .exe and .dll are affected, and .txt is not. Is there some definitive guide on this? I'd like to get rid of these extra flags on my file items if they serve no purpose.
The general recommendation I always give is to absolutely always use ignoreversion on every file in {app}.
It causes no harm on files without resources (and potentially improves performance in that Inno doesn't have to waste time discovering that they lack resources), and is almost always what you want for app files (otherwise you can end up in some weird frankenstate with a mixture of files).
However for files installed outside of {app} (typically either {sys} or {cf}) you usually should not use ignoreversion and should instead only permit upgrades. But YMMV.
(Note that special care may need to be taken for ensuring upgrades of common files outside of {app}, as only EXE and DLL files typically have version information, and even some of those may lack it or it may not be updated consistently, depending on the source of the file. Other considerations also apply to common files, such as using sharedfile.)
(Promoted comment to answer.)
For which file types is the "ignoreversion" flag meaningful ?
For those that can have Windows resources. Version information reading in Inno Setup falls deep down to Windows API so it's actually the system which determines from which files the version information can be read. Currently, the About Version Information topic specifies the files, that can have version information briefly as:
You can add version information to any files that can have Windows
resources, such as DLLs, executable files, or .fon font files.
Which narrows the list of possible files to the list of files that may contain resources. Unfortunately, there is no (and cannot be) a list of extensions of files, that might contain resources, because you can have a file with version information having some exotic file extension (I've asked for it a long time ago).
So, there is no credible advice, for which files you should keep or remove this flag.
Is the "ignoreversion" flag really intended ? When should I use it ?
More it makes me wonder, why to include the ignoreversion flag. I would say it should be used rarely and carefully only there, where you are sure a possible downgrade of a certain file won't hurt. Without it, the Inno Setup compares version of the installed file with an existing one and replaces it when it's older, which is in my view the most wanted behavior.
The version flags refer to the version of your application installer package and not to the DLL version of a file shipped with the installer. Because of this .txt files also have a version and the 'ignoreversion' flag makes sense for any file within the installer package. It's up to the developer to trace and adjust the file updates between application versions using any of the InnoSetup provided flags.
Related
I observe that .convert files look similar to .override files. Override files end with .gschema.override suffix. I believe that gsettings-data-convert or any other utility creates the .override files. I am looking forward to any link that can explain the complete conversion process.
GSettings vendor overrides and .convert files for gsettings-data-convert are very different.
Vendor overrides are used to allow OS vendors (for example, a particular Linux distribution) to override the default values of settings shipped by an application or part of the desktop, without having to patch the code for that application. They are used quite commonly.
.convert files were historically used to map GConf keys to GSettings schema keys, so that data stored in GConf could be migrated to GSettings/dconf without manual migration code having to be written. Now that GConf has been deprecated since 2011 and unmaintained since 2013, the need for .convert files has dropped off. There should not really be any applications left using GConf (if they are, they need to migrate away from it ASAP). Hence you wouldn’t normally ever need to use a .convert file any more.
I've defined a CMakeLists.txt file for my project which works correctly.
I use the CMake GUI for generating a Visual Studio Project, and I ask to build the binaries (CMAke cache and other stuff) in the folder Build which is in the same folder where CMakeLists.txt is.
I was able to specify where the executable and the libraries have to be created.
Is there a way to specify also where the Visual Studio Solution file has to be created? I would like to have it in the root directory, but at the same time I don't want to have also all the other files that CMake creates in the Build directory.
CMake creates the Project I defined in CMakeLists.txt but also two other projects: ALL_BUILD and ZERO_CHECK. What's their utility?
I was able to avoid the creation of ZERO_CHECK by using the command set_property(GLOBAL PROPERTY USE_FOLDERS On).
Is there a way for avoiding also the creation of ALL_BUILD?
It seems you only switched to CMake very recently, as exactly those questions also popped into my head when I first started using CMake. Let's address them in the order you posted them:
I use the CMake GUI for generating a Visual Studio Project, and I ask
to build the binaries (CMAke cache and other stuff) in the folder
Build which is in the same folder where CMakeLists.txt is.
Don't. Always do an out-of-source build with CMake. I know, it feels weird when you do it the first time, but trust me: Once you get used to it, you'll never want to go back.
Besides the fact that using source control becomes so much more convenient when code and build files are properly separated, this also allows to build separate distinct build configurations from the same source tree at the same time.
Is there a way to specify also where the Visual Studio Solution file has to be created?
You really shouldn't care.
I see why you do feel that you need full control over how the solution and project files get created, but you really don't. Simply specify the target for the solution as the origin of your out-of-source build and forget about all the other files that are generated. You don't need to worry, and you don't want to worry - this is exactly the kind of stuff that CMake is supposed to take care of for you.
Ask yourself: What would you gain if you could handpick the location of every project file? Nothing, because chances are, you will never touch them anyways. CMake is your sole master now...
CMake creates the Project I defined in CMakeLists.txt but also two
other projects: ALL_BUILD and ZERO_CHECK. What's their utility? I was
able to avoid the creation of ZERO_CHECK by using the command
set_property(GLOBAL PROPERTY USE_FOLDERS On). Is there a way for
avoiding also the creation of ALL_BUILD?
Again, you really shouldn't care. CMake defines a couple of dummy projects which are very useful for certain internal voodoo that you don't want to worry about. They look weird at first, but you'll get used to their sight faster than you think. Just don't try to throw them out, as it won't work properly.
If their sight really annoys you that much, consider moving them to a folder inside the solution so that you don't have to look at them all the time.
Bottom line: CMake feels different than a handcrafted VS solution in a couple of ways. This takes some getting used to, but is ultimately a much less painful experience than one might fear.
You don't always have a choice about what your environment requires. Visual Studio's GitHub integration requires that the solution file exists in source control and is at the root of the source tree. It's a documented limitation.
The best I was able to come up with is adding this bit to CMakeList.txt:
# The solution file isn't generated until after this script finishes,
# which means that:
# - it might not exist (if this is the first run)
# - you need to run cmake twice to ensure any new solution was copied
set(sln_binpath ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln)
if(EXISTS ${sln_binpath})
# Load solution file from bin-dir and change the relative references to
# project files so that the in memory copy is as if it had been built in
# the source dir.
file(RELATIVE_PATH prefix
${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_BINARY_DIR})
file(READ ${sln_binpath} sln_content)
string(REGEX REPLACE
"\"([^\"]+).vcxproj\""
"\"${prefix}/\\1.vcxproj\""
sln_content
"${sln_content}")
# Compare the updated contents with the existing source path sln, if it
# exists and is the same we don't want to disturb VS by touching it.
set(sln_srcpath ${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}.sln)
set(old_content "")
if(EXISTS ${sln_srcpath})
file(READ ${sln_srcpath} old_content)
endif()
if(NOT old_content STREQUAL sln_content)
file(WRITE ${sln_srcpath} ${sln_content})
endif()
endif()
What would be helpful is if cmake had a way to run post generation scripts, but I couldn't find one.
Other ideas that didn't work out:
wrap cmake inside a script that does the same thing, but:
telling users to run a seperate script isn't simpler than saying to run cmake twice. Especially since needing to run cmake twice isn't a foreign concept.
put it in a pre-build step, but
building is common and changing the build is rare
changing the solution from builds inside the IDE makes it do... things
use add_subdirectory because that's suppose to finish first
it appeared to make the vcxproj's immediately, but not the sln until later, but I didn't try as hard because this adds a bunch of additional clutter I didn't want - so maybe this can be made to work
I am making an inno setup script. My setup really needs the user to choose to two customized install locations.
But there is only one {app} variable in inno.
Our software is an audio plugin software, the common way in this field is to choose one location for the program and the other location for audio sample/data (which is very large so users usually want to install at a dedicated place for storage and also performance purpose).
Is there any way to get around this condition?
Thanks a lot!
There are many other variables (Directory Constants) which you can use, most common ones:
{app} - The application directory (user chooses this derectory in Wizard dialog)
You can create subdirectories like {app}\Data
{win}
The system's Windows directory.
{sys}
The system's System32 directory.
{pf}
Program Files.
{cf}
Common Files.
And many, many others.
The modern installers store application in one directory - {app} and user's files in every user's custom directory - e.g. {localappdata}.
And if this is still not enough you can create your own dialog (wizard page) that contains edit boxes and Browse buttons for selecting directories.
Use function CreateInputDirPage() for this purpose.
See manual - Pascal Scripting: CreateInputDirPage for more info.
Take a look at the included CodeDlg.iss example that shows how to add an extra page for a data directory and hwo to use that value in [Code].
I installed the multilib version of mingw-w64 so I could build both 32-bit and 64-bit binaries. Here's a tree representation of the files: http://pastebin.com/r4QUnbwJ. If you only want to view the directories, see this instead: http://pastebin.com/2m6uqt4E. It looks like there are duplicate files in some cases, like in the bin directory. Are they different in any way? Also, I see one directory named "mingw" and another named "x86_64-w64-mingw32". They look about the same in content. Again, what is the difference?
Basically, I just want an explanation of the file layout. I'm not expecting a description of each file, but it would be good if some of the main concepts within mingw-w64 (multilib) were addressed.
In my experience, the /mingw directory can safely be deleted. It is only needed for the strange GCC build system (and can even be empty in some cases).
The x86_64-w64-mingw32/bin directory contains executables called by gcc/g++/gfortran/etc. internally. Don't delete them.
There doesn't seem to be a "standard" directory structure, sometimes the x86_64-w64-mingw32/lib(32) and x86_64-w64-mingw32/include directories contain the same files. Sometimes the same files are even in the root include and lib(32) directories. If you need an expert's answer, feel free to post to the minwgw-64 mailing list, a lot of knowledgeable people reside there.
I wanted to write an NSIS script, let's call it for now setup.nsi, and check
if several required dll files already exists in $SYSDIR
Let me emphasize on the word "several"
What I understand from nsis IfFileExists documentation is that if I type in:
IfFileExists $SYSDIR\blabla.dll +2 +1
then it checks if blabla.dll is in $SYSDIR .. but what if I want to know if *.dll from where setup.nsi copies the file (i.e. the *.dll's that I am interested in installing in.. and they are a lot of them.. so I can't just go around checking for all the names) exists in $SYSDIR
During uninstallation I want to then be able to delete them from $SYSDIR (using some uninstall.log to see if I really copied them in $SYSDIR.. and again the wildcard question).
Please be patient with me as I am really new to NSIS scripts.
Is it REALLY necessary to write and delete in $SYSDIR ? Unless yours is a system file, there's no reason for it to be in $__SYS__DIR. If you need to use a specific version of a library, consider DLL redirection (put your DLL in your app dir and use the .local feature) - see the MSDN article on DLL redirection and Side-by-side assemblies.
Plus, you are one typo away from wrecking the user's computer ("Deleted: C:\Windows\System32\user32.dll").
As Piskvor mentions, I don't think you should be worrying about deleting system DLLs in the uninstaller. In case you want to overwrite system DLLs with an updated version, you may want to look at the SetOverwrite command. It lets you overwrite files if what you've got is newer.
Windows XP (SP2?) and up has file protection for system32, so you can't overwrite system critical files in there.
Do try to stay away from that.
Also, to check for your file specifically, see if there's a plugin for NSIS that can calculate checksums and compare that on uninstall. That's probably the safest, IF you really need to do it.
I'd suggest install files somewhere else and add that to PATH.