It seems that whenever a build_always_stale: true target is rebuilt, it is also assumed to be changed by the rebuild, even if the output file is factually bit-for-bit unchanged. This causes targets depending on the build_always_stale target to also be rebuilt every time. Is this part of the semantics of build_always_stale?
I thought that build_always_stale just meant "we don't know how to determine whether this target is up to date, so please always rebuild it just in case", but it seems it also includes "and please consider the result to be always changed even if it isn't"?
Is this part of the semantics of build_always_stale?
That's up to the underlying build system to decide. On its end, meson just makes sure that the target is always rebuilt, no matter what.
Taking the ninja backend as an example, and taking a look at the generate_custom_target function in its source code in particular, you'll see this:
if target.build_always_stale:
deps.append('PHONY')
Which means that, if a custom target is marked as always stale, meson will tell ninja to add PHONY as its dependency.
In that case, ninja will always assume that the target is out of date, and thus that all of its dependents are out of date as well.
Related
I have been working on a big SQL based project that is taking an increasing amount of time and effort to maintain its versions. Lets keep it simple. I have three folders for each version of the code called Ver1, Ver2, and Ver3. All three version folders have the exact same filenames within it, but their content differs from version to version. If I make a change to a particular file in Ver3 that exists in Ver2 and Ver1, how can I use Git not to necessarily make the same changes in those other versions (not always practical due to partial rewrites for performance or logic changes), but to let me know that the other two versions of the file need to be updated in order to catchup to the Ver3? If Git isn't suited for this task, or if you have any experience with a similar issue, I would much appreciate any suggestions.
What do I miss in using CPackDeb? (cmake version 3.5.1)
For example, if I want to find out CPACK_DEBIAN_PACKAGE_ARCHITECTURE, an empty string is returned. If I clone the respective code, everything works as expected. Also, other
https://cmake.org/cmake/help/v3.0/module/CPackDeb.html specific variables seem to not work, and also my KDevelop does not highlight them.
Since using include(CPackDeb) results in error message CPackDeb.cmake may only be used by CPack internally, I presume there is some other way (a missed parameter?) to activate it.
We have a C++Builder XE project (VCL Forms Application) that has a few dozen forms and units in it. Whenever a file belonging to the project is added, deleted, or renamed, the IDE should do two things:
A call to USEFORM macro is added to or altered in the Project Source file (ProjectName.cpp) if the affected unit is a form or frame
A CppCompile element in the project file (ProjectName.cbproj) is added or altered
However instead of just doing the necessary changes, the IDE shuffles some of the existing USEFORMs and CppCompile records, even if they aren't affected by the changes. If I add a Unit (cpp and header file), the USEFORMs are shuffled even when that wouldn't require any changes to the Project Source, only to the cbproj-file.
I don't see a specific pattern on how the new order is formed. If I edit or rename a single unit, about half of the USEFORMs seem to change position and just a couple or none of the CppCompile records. If a change is made to a copy of the project in two different machines, most of the changes seem to be similar, but not all. This indicates that the reordering is not random.
The behaviour causes problems when using Subversion to merge changes, because it forces to manually resolve conflicts inflicted by the changing order.
So the question is: What might be causing the foregoing behaviour and how to get rid of it?
I haven't been able to find a proper solution to the problem, but here's a simple method for making it slightly less annoying:
Adopt a policy of never committing the random IDE-generated changes to the version control repository. Whenever you make changes to code that trigger mixing up the files, revert all unnecessary changes in ProjectName.cpp and ProjectName.cbproj. At this point it is still fairly easy, as you know which parts of the files actually should have changed. That way, the manual labour is carried out when it still requires the minimal amount of work. Additionally, the work has to be carried out only once, in contrast to leaving the changes untouched, in which case the work has to be repeated every time someone merges the changes.
I have two targets in my project with overlapping classes.
I converted one target to arc and now I can't convert second target, beacues files common with first target are already converted. Unchecking these files during conversion not working.
Please help!
I've run into similar problems in the past. The solutions that I came up with weren't particularly elegant, but they did work.
If the second target has a small amount of changes over the first, you can go in to Xcode and change the Objective-C Automatic Reference Counting setting to YES for the second project and then manually fix the problems. This works OK for a small number of files, but isn't as comprehensive.
For significant changes, I ended up using my source control system (Perforce in my case, but git, hg, whatever should work fine) to temporarily roll back my changes for the first target and re-apply them to the second target so that I could use the automated tools, then I did a diff between the files that were changed in both runs to make sure that the changes were the same (I don't recall any differences).
So. The most painless method I figured out was to add second target as build dependency to the first one. Select both in conversion dialogue, and then remove this dependency after conversion. It 100% works.
Using VB 2008
When I press the F5 or Start Debugging it does a rebuild even when I have made no changes since the last time. Where is the setting to tell it to only do a rebuild if there are changes?
F5 should a build and not rebuild, are you sure it's a rebuild? Even you do not make any changes, a 'pseudo' build is still executed, and should be significant faster than a normal build or rebuild.
EDIT:
My definition of a 'pseudo' build is to check for need to build and/or making sure all files required for debugging are present (e.g. pdb files)
In my installation, F5 (Start Debugging) only builds when changes have been made. This includes changes that don't actually effect the code (like modifying comments). If I do F5, close the program, and push F5 again (without changing anything), no rebuild takes place. Is there something I'm missing?
As other have mentioned, Visual Studio only rebuilds what it thinks needs rebuilding.
My advice is to check what it actually builds, to see what made the build system think it was out-of-date. I've often seen this issue when, e.g., a custom build step was used, and the output of the step was specificed incorrectly. So VS is expecting a built file (because you told it it would be there), and since the built file is not there, it restarts that specific build step, along with all the projects that depend on the project containing the build step.
This is just one example. It usually boils down to an expected generated file that gets moved or is missing.
If this does not help, maybe a build log would help identifying your issue in more depth.