I notice that after running "make" then running "make install", the build will go through the whole compile/profile/compile process again. This is really infuriating behaviour, given the extremely long make time for the profiled optimized build.
The problem appears to me to be that the "profile-opt" target does not have proper dependencies. I think changing it to:
should fix it. If my "make install" ever finishes, maybe I will test it. ;-)
Okay, my initial idea was wrong (I blame years of not having to look at Makefiles). I think the attached patch works. It uses a "stamp" file to record the fact that the profiled build is complete.
The fix is sub-optimal because changing some source code and re-running "make" will not rebuild as needed. That would require proper dependencies in the Makefile, rather than treating "make" as an imperative scripting language (e.g. recursively calling make to sequence things). Given that the profile optimised build is unlikely to be used during development, I guess that's not so bad.
The previous behavior nearly drove me to drink. At least on my machine (and I have a relatively fast one), the profile-opt build takes a long time. After running "make" and checking things over, running "make install" will cause the whole process (make clean, make with -fprofile-generate, run unit tests, make clean, make with -fprofile-use) to happen again. The profile-opt build is significantly faster so I like to use it. Maybe I'm an odd duck in that I usually compile Python myself rather than using distro packaged versions.
Current behavior is much better I think. You have to know to manually remove "profile-run-stamp" if you want the -fprofile-generate + unittest to run again. "make clean" does not remove it. I don't know if that should be documented somewhere besides in the Makefile.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
The text was updated successfully, but these errors were encountered: