I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
Related
I opened my project on another computer, and the files where I'd been using a file watcher were expanded, like before they used to be nested like home.scss is now after I run the watcher once on that file.
Is there a way to automatically make all the files be nested?
Because when adding new files and folder with git, it would be quite troublesome to go into each and every file in order to make them become nested.
Like I have some minified JavaScript files that used to be nested, but now is expanded for some reason.
Hope you understand. Thank you.
Edit: Nested***
Is there a way to automatically make all the files go under a caret like that?
Unfortunately not. Such nesting information (to "go under a caret" as you are saying) is taken from "Output path to refresh" field of the corresponding File Watcher.
You have to run file watcher for such files at least once in order to see files nested like you have it on your another computer.
Here is how you can run File Watchers manually without the need to modify those files (so no extra history will appear in your git (or whatever VCS you may be using there)).
https://stackoverflow.com/a/20012655/783119
P.S.
In PhpStorm 2016.3 (the next version that will be released in 1.5-2 months or so) such nesting will be done automatically (the most common combinations) so there will be no need to have File Watchers for providing such info.
If you wish -- you can try EAP build right now (EAP means Early Access Program .. which is sort of Alpha/Beta builds (simply speaking).. and therefore some bugs for new functionality might be present and performance may not be optimal).
I am trying to create a rpm using mock. https://fedoraproject.org/wiki/Projects/Mock
I am able to build an rpm through source rpm. Now I want to add a patch to this package and I have no idea how to proceed. Can you please let me know how can I go ahead with this? What is the way to modify/patch a package using mock?
The normal approach here is not to use mock to modify your package in any way. Mock is just a way to ensure that your package is built in a clean environment every time (a fresh chroot), and it's not really meant to do more than that.
The normal thing to do, then, would be to put the patch in the spec file for your RPM itself.
This requires two parts — first, the inclusion of the patch file as part of the package, and second, its application.
For the first, list the patch near the top of the spec file, usually right after your Source line (or lines). Each patch gets a number, and the normal convention is to start counting with 0, so if you have just one, that will look like this:
Patch0: packagename-version-terse_patch_description.patch
As with source files, anything up to the last / in that filename is stripped off, so you can use a URL if you want. The patch will need to be in your RPM sources directory (usually, next to the tarball.)
At this point, if you build a source RPM from your modified spec, the resulting src.rpm file will contain this patch file. (Try it — rpm -qlp packagename-ver-rel.src.rpm). But, it won't be applied. To do that, you need to use the %patch macro.
This goes in the %prep section of the specfile, usually right after the %setup macro line. Each %patch macro has a number corresponding to the Patch line in the header, so for your Patch0, add a line like this:
%patch0 -p1 -b .bugfix
Again by convention, patches used in RPM are made built one level up, so -p1 is appropriate. (Conveniently, this will be correct for diffs made with git, too.) And the -b .bugfix bit isn't necessary, but it's customary for debugging, and I guess serves as a sort of inline comment for what this specific patch macro does. (Replace the string "bugfix" with something appropriate to your actual patch.)
I want to set different hex file names for different configurations of a project. In detail I want to have a release configuration where compiler optimization is turned on and a debug configuration where optimization is turned off.
So far I have discovered the possibility to add a second configuration to the project, where I can set a different optimization level. The binary for the other configuration is automatically compiled to another directory but the name of the result hex file stays the same. I tried to change the macro "ImageName" under the "Building" options for the configuration but they are read only and the makefiles containing these macros seem to be automatically regenerated so manual changing is futile.
Is there any way to separate these two builds (one with optimization and one without) by name of the result file? I don't want to release a build without optimization by accident since this is really critical in my current project as I already have experienced.
Use the Execute this line after build option. It is right above the Macros section (Right Click > Properties > Conf:[name] > Building). Commands you type there will be inserted into the auto-generated makefile (nbproject/Makefile-$CONF.mk) and executed at the end of the build process.
Example:
To copy the output hex file to "out_dir" and tag it with the configuration, use this line:
${MKDIR} out_dir && ${CP} ${ImagePath} out_dir && ${MV} out_dir/${ImageName} out_dir/${ConfName}_${IMAGE_TYPE}.${OUTPUT_SUFFIX}
This line will create "out_dir/", copy the hexfile to the "out_dir" folder and then rename the hexfile to configuration-name_build-type.hex.
I have two libraries libA and libB.
libA contains a file Action.h
libB contains a file action.h
I want to generate doxygen documentation in the same output directory for both libraries. This directory is to be used in Windows, for which action.html and Action.html is unfortunately considered to be the same file. To prevent this clash, I wish to render the generated files unique by prepending their path names to them.
Therefore, I set FULL_PATH_NAMES to YES.
I expect to see something like libA_Action.html and libB_action.html when I generate the documentation, but I don't! I still see Action.html and action.html. Its as if the FULL_PATH_NAMES parameter does nothing at all. Do I also need to set some other parameter in the Doxyfile to make the FULL_PATH_NAMES parameter work correctly?
You're probably running doxygen twice - one time for each library. If that is the case, doxygen isn't aware of the fact that it might clash with an output from another run, so when it find an existing file, it assumes that it is leftover from a previous run, and overrides it.
Setting FULL_PATH_NAMES doesn't help, as doxygen has no idea that multiple libraries exist, so, as far as doxygen is concerned, the prefix is identical to all files, so even when you adding a force it, it adds nothing (That's probably a bug).
The solution to your problem is setting both libraries as inputs to the same doxygen project.
You can do it by setting INPUT to multiple folders in the configuration file:
INPUT = ...bla\Lib1 \
...bla\Lib2
I'm working on some code with a partner. Our make files differ slightly courtesy of different build setups. Because of this, so far we have not been tracking this file. However it would be nice to have at least one of ours tracked. The problem is, when that is done and the other person runs hg update, their copy gets update and the code won't compile.
Is there a way to track the file, but have it such that you can update the working directory selectively? Or is there some other way I should deal with this problem?
This is a slight variant of the standard "how do I deal with a config file" question. The standard answer in SVN, Mercurial, and Git is: don't track the file, instead track <file>.example. Then each user copies that over to <file> and tweaks it as needed.
But Makefiles are a bit smarter than config files: they execute code and can include other files. In which case, it starts making sense to track the Makefile normally and have it include another local file if it's present that overrides the default rules. For instance, the following will work with GNU Make:
# pull in any local user tweaks
-include Makefile.local
MQ extension is the best and The Right Way (tm) to do it (not easiest, but...)
Store common part of file in repo, individual personalisation - in own MQ-patches
Is it possible to combine your Makefiles? Then there is not chance of losing your different configurations by not storing them in version control.
For example, you could add a conditional statement based on the username. My username is ryan and this code echos my name, but if it is run on your computer, it probably will echo "not ryan."
all:
if [ `whoami` = "ryan" ]; then echo "ryan"; else echo "not ryan"; fi