I stumbled upon an issue when I recently switched to VSCode as editor.
I have several projects that have a full (medium-complex+) autotool
setup and they all work fine. However I discovered that the makefile plugin for VSCode in order to initialize itself (and finding all dependencies and targets) starts by running
make --dry-run --always-make
as first time initialization. This throws the makefile (or actually the
re-config) into an endless loop re-running "configure" (since the targets are never resolved to disk).
I have also confirmed this behavior with the smallest possible autoconf/automake
setup. I can also kind-of understand why this happens (and it seems make
have an internal way to discover this exact situation with the special
variable MAKE_RESTARTS that could possible be used to detect a cyclic
behavior)
Is there a known best-practice workaround ? or is it even a reasonable expectations that these two options in combination should work? (Good to have a second opinion before I go down the rabbit-hole of reminding myself of all the details I forgot about the magical land of autotools)?
Related
I have this patch developed for mailman-2.1.13, and I would like to port it to mailman-2.1.15
I never did this before, so I'm asking for advices here. How would you go about this task ? Here are my thoughts on the subject :
I could search the 2.1.15 codebase for code segments corresponding to the patch, but I would miss any new part depending on the patched code.
I could look at the diff between 2.1.13 and 2.1.15 and search for parts conflicting with the patch, at the risk of drowning into the many changes between the versions
I could simply rewrite the patch but I would need to understand all the logic of the patched application, which could be quite long ...
Your advices are welcome !
The keywords for search are "rebase", "merge" and "conflict".
A conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other.
You would find that resolving conflicts (e.g. porting patch to newer version) is usually not trivial operation and cannot be done correctly without deep understanding of code you work with.
Really depends on the change in main code base from mailman-2.1.13 to mailman-2.1.15, but sometimes it is easier to rewrite patch from scratch, sometimes it is sufficient to merge changes from patch to new version and try to fix the conflicts/problems it makes.
I would start with finding out what was the original problem that patch wanted to solve and how it was solved. Then look to 2.1.15 code and find out if the original problem is still there and if it is possible to apply the patch directly (internals didn't change so much in meantime) or new approach must be applied.
I have added a reference to a DLL from another project (contained in the bin folder) and I have set Copy local to true. When I step through the code; the debugger jumps all over the place. I believe this is because the code is optimised. I have two questions:
Is this because the code is optimised
If (1) is true then why can I step through the code in the first place i.e. without Reflector.
My guess is the jumping is due to the PDB (symbols) being out of sync with the compiled DLL, thus the symbols tell VS to go to a line number that does not actually match up with what the code is actually doing; optimization may also play a part as well, because of in-lining functions.
Other things that influence the debugging experience are:
Just My Code setting
Methods explicitly marked with DebuggerNonUserCode attribute
Debugging optimized code may "jump around", as some functions become inlined. The most telling thing is that local variables usually get optimized away, giving a message to that effect when trying to read them.
If the jumping seems to make very little sense, though, then it's more likely you have the wrong PDB (which maps to line numbers) or source (which has the line numbers).
Recently, I've noticed strange behavior by Subversion. Occasionally, and seemingly randomly, the "svn up" command will wreak havoc on my CSS files. 99% of the time it works fine, but when it goes bad, it's pretty damn terrible.
Instead of noting a conflict as it should, Subversion appears to be trashing all incoming conflict lines and reporting a successful merge. This results in massively inconvenient manual merges because the incoming changes effectively disappear unless they're manually placed back into the file.
I would have believed this was a case of user error, but I just watched it happen. We have two designers that frequently work on the same CSS files, but both are familiar and proficient with conflict resolution.
As near as can figure, this happens when both designers have a large number of changes to check in and one beats the other to the punch. Is it possible that this is somehow confusing SVN's merging algorithm?
Any experience or helpful anecdotes dealing with this type of behavior from SVN are welcome.
If you can find a diff/merge program that's better at detecting the minimal changes in files of this structure, use the -diff-cmd option to svn update to invoke it.
It may be tedious but you can check the changes in the CSS file by using
svn diff -r 100:101 filename/url
for example and stepping back from your HEAD revision. This should show what changes were made , at what revision and by whom. It sounds like a merging issue I've had before but unfortunately I found myself resolving it by looking at previous revisions and merging them manually too.
I'm not sure if this is standard behavior for IDEs, but I personally find it irritating. If a file produces warnings when built (unused variables, mismatched ints/longs/etc.), those warnings will cease to be displayed if another file is modified and the "Build project" button is clicked. Doesn't it make more sense for warnings pertaining to unmodified code to continue to be displayed? Is there a way to force this behavior?
The warnings are displayed when the compiler emits them -- unfortunately, that's the design decision taken by both VS team (up to 2008 at least) and by Qt Creator team.
It seems to be standard behavior, and I don't know of any options to override it. It should be easy to fix in Qt Creator, but may be hard to fix in Visual Studio unless relevant APIs are present. For VS you'd need to write an add-in and there would need to be an API available that gives you read-write access to the error list and to the build process. If such APIs exist, then it'd be a simple thing to do as well.
This is "standard behavior", and more specifically, behavior is an attribute of how build systems on Earth "are-designed-to-behave".
As #Kuba notes, the warnings are emitted by the compiler. They aren't stored (except in the "log-of-all-errors/warnings" for the build operation, which the IDE typically never reads-back-and-excerpts-from-for-future-build-operations, which would get their own log of their new warnings/errors). Thus, you won't see the warning again unless the compiler actually compiles the file again, and that's because they would be new warnings that are generated again by the new build operation.
To get what you want (a clever thought, IMHO), the build system would need to:
store warnings from each file-compile (probably on a "per-file-basis")
recall/display those warnings each time that file-output-product was "used"
Very clever. I'm not aware of any system that does that. It would require fairly significant IDE or build-tool-level management of build products, which IMHO, none of them do well (but some are better than others).
This is the year 2012, and not only are we missing our flying cars, but we're missing build systems that merely/quickly build-only-what's-required-using-all-cores while easily handling different configurations. Both were expected by now.
Then, sometime after that, you could probably get your feature. That would be a bonus, because then you could use it in your flying car.
We have an autotools project that has a mixture of unit and integration tests, all of which run via 'make check'. This isn't ideal, as some of the integration tests take a while, and have all sorts of dependencies (database, etc.)
I'd like to separate the integration tests and assign them their own make target. That way, unit tests can still be run often (via make check), and the integration tests can be run as needed in a similar fashion.
Is there a straightforward (or otherwise) way to add an additional make target?
NOTE: I should probably also add that this is a large project, so editing/maintaining every makefile by hand is not desirable. I'd like to do it the 'autotools way' if possible.
-- UPDATE 1 --
I've attempted Jon's solution, and it's a step closer, but not quite there. I still have a couple of issues:
1) Recursion - I'm OK with modifying the makefile.am in the root of the build tree, as well as any directory that contains the tests, but it seems like there should be a way to do this where I don't have to change every Makefile.am in the hierarchy. (the check target works this way, after all)
2) .PHONY - I keep getting messages about .PHONY being redefined. Which is understandable, because it's being set by another package (specifically, doxygen). How do I make the two play nice together?
In your am files, all make syntax is passed into the generated Makefile. So if you want a new target just create it like you would in a Makefile and it will appear in the auto generated Makefile. Put the following at the bottom of your am files.
integration-tests: prerequisites....
commands to run test
.PHONY: integration-tests
Since there haven't been any more responses, I'm going to answer with my solution.
I solved the recursion issue by eliminating the recursion altogether. Using this page
as a guide, I switched the entire project from recursive make to non-recursive make. I then cloned the non-recursive check-related targets (check, check-am, check-TESTS, etc.) into a new set of targets for the integration tests. So far, this works extremely well.
Note: you may be wondering why I didn't just clone the recursive targets instead. Quite frankly, I couldn't find them. Either I didn't know where to look (the rules weren't in the generated Makefile) or something is happening implicitly, and I don't understand autotools well enough to follow it.
As for the issue with .PHONY being redefined, I still haven't found a solution, other than to conditionally exclude the other definition when I'm doing the integration tests.