In TCL source tree, unix/Makefile, I notice that header files are not part of dependency of any C source file. For example:
tclCmdAH.o: $(GENERIC_DIR)/tclCmdAH.c
$(CC) -c $(CC_SWITCHES) $(GENERIC_DIR)/tclCmdAH.c
This ends up, if I update tcl.h and run make, the change is not picked up at all. I need to totally clean the directory and then run make.
Did I miss anything? Or any reason is it done this way?
Related
I'm working on a commit hook for Mercurial and running into problems with relative paths.
Say my hook wants to look at the contents of the files being committed and warn if any contain the phrase "xyzzy". However, the user has decided to call commit from a subfolder and pass in the name of the file as a pattern...
C:\clone\subdir> hg commit file.txt -m 'test'
My hook is called with C:\clone as the working directory, but HG_PATS contains simply file.txt with no subdir\ prefix. How can I get the working directory of the hg command itself? I can't find a way to do this in docs.
The only way I can figure out how to get it is look up the process tree to find the first hg.exe and get its working directory. But that's not exactly portable to other OS's. (And I know I could write an extension, but would really like to avoid that.)
If you use the pretxncommit hook then you are given $HG_NODE which is the commit id, but the commit hasn't been finalized at that point so you can still return 1 to cancel it.
Then you could use
hg log -r $HG_NODE --template '{files}'
to get the list of files in the commit, and it gives you the full path relative to the repo root.
It's not exactly what you were after but it might get you close enough to let you do the content examination you want.
Thanks for the answers and comments, but after some more research I determined there's no clean way to do what I want from an external hook. I did implement the CWD hack I mentioned in my question. Not a ton of code, but quite nasty, and on Windows it requires undocumented access to external process CWD via tlist.exe. It works, but..yuck.
The right way to do this appears to be to write an in-process hook (example library at hghooklib). Usual versioning caveats apply as with writing any extension, though I think for our hooks the interface to hg is simple enough that we'll be ok.
(In my question I mentioned I didn't want to write an extension, but I was thinking of a full extension like hgeol. A hook-only extension with a single function entry point feels more constrained and simple, which is what I want at this point.)
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 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.
Using doxygen 1.8.4 on Ubuntu 12.04
Generating for C/C++ source into an RTF file.
I'd like to disable the generation of the Index at the end of the document.
There are many hits for DISABLE_INDEX but this is the index at the top of HTML pages, not the main index at the end of the file. I've also searched the documentation for configuration for "index" and none of the hits seem to be about that particular index.
Update: This is also set to NO:
ALPHABETICAL_INDEX = NO
I looked in the DoxygenLayout file and there doesn't seem to be anything specific about the Index section. There are sub-indexes for namespaces, classes, and files. But nothing that I can see for the Index section. I'm not even sure if the DoxygenLayout file is used for RTF files, because of this comment:
<!-- Navigation index tabs for HTML output -->
Any help or pointers will be greatly appreciated!
TIA
John
Well this isn't an answer for this exact post. But it does indicate how to disable the generation of indexes and table of contents for Latex/PDFs.
set GENERATE_LATEX=YES and MAKEINDEX_CMD_NAME = echo
run doxygen to generate the latex file refman.tex
cd into the output directory named in LATEX_OUTPUT (typically "latex")
copy the Makefile to another directory and edit it:
remove all calls to "pdflatex refman" except the first
remove the loop
remove all calls to "echo refnam.idx"
It will look something like:
all: refman.pdf
pdf: refman.pdf
refman.pdf: clean refman.tex
pdflatex refman
clean:
rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out *.brf *.blg *.bbl refman.pdf
cd into the output directory again and invoke the modified Makefile
cd latex
make -f ../../doc/Makefile
take a look at refman.pdf. The Table of Contents is gone, the Index is gone.
Caveat: So this works in latex output but does not work for RTF.
For my project, I've converted back to using latex, and so is a solution for me...
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