Search Results

Search found 32 results on 2 pages for 'gnumake'.

Page 1/2 | 1 2  | Next Page >

  • How can I capture GNUMake differences between two directories

    - by WilliamKF
    I have a tricky issue with gmake, when I build from the parent directory, something is different and the make does not build all the .o(s) it needs and fails, but if I cd to the directory and do a make it builds them fine. How can I get GNUmake to tell me the difference between these two runs? There must be some make variables set in the parent that break the child, but I need help figuring out how to track them down.

    Read the article

  • Why does Gnumake from parent directory behave differently?

    - by WilliamKF
    I am stumped as to why when I do a gnumake from the parent directory it behaves incorrectly, whereas, if I cd to the subdirectory and do gnumake it works correctly. In the parent makefile, I have a rule like this: .PHONY: zlib-1.2.5 zlib-1.2.5: @ echo Issuing $(MAKE) in $@ ... pushd zlib-1.2.5; make; popd Which gives different result than doing the same from the toplevel pushd zlib-1.2.5; make; popd There is a something from the parent makefile that is making its way into the subdirectory makefile and causing it to behave incorrectly, but I don't know how to find it. The symptom I see is that the subdirectory config generated makefile rule for zlib misses the dependencies and I get this result going straight to the ar without generating the .o(s) first: cd ~/src; make zlib-1.2.5 CPPFLAGS_AUTO = < > Issuing make in zlib-1.2.5 ... pushd zlib-1.2.5; make; popd ~/src/zlib-1.2.5 ~/src make[1]: Entering directory `/disk2/user/src/zlib-1.2.5' ar rc libz.a adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o ar: adler32.o: No such file or directory make[1]: *** [libz.a] Error 1 gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.5 adler32.lo compress.lo crc32.lo deflate.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo uncompr.lo zutil.lo -lc -L. libz.a gcc: adler32.lo: No such file or directory gcc: compress.lo: No such file or directory gcc: crc32.lo: No such file or directory gcc: deflate.lo: No such file or directory [...] make[1]: *** [libz.so.1.2.5] Error 1 make[1]: Target `all' not remade because of errors. make[1]: Leaving directory `/disk2/user/src/zlib-1.2.5' ~/src Versus from the zlib directory where it works correctly: cd ~/src/zlib-1.2.5; make gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o example.o example.c gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o adler32.o adler32.c gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o compress.o compress.c gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o crc32.o crc32.c [...] gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o zutil.o zutil.c ar rc libz.a adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o (ranlib libz.a || true) >/dev/null 2>&1 gcc -O3 -D_LARGEFILE64_SOURCE=1 -o example example.o -L. libz.a gcc -O3 -D_LARGEFILE64_SOURCE=1 -c -o minigzip.o minigzip.c gcc -O3 -D_LARGEFILE64_SOURCE=1 -o minigzip minigzip.o -L. libz.a mkdir objs 2>/dev/null || test -d objs gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DPIC -c -o objs/adler32.o adler32.c mv objs/adler32.o adler32.lo mkdir objs 2>/dev/null || test -d objs gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DPIC -c -o objs/compress.o compress.c mv objs/compress.o compress.lo [...] mkdir objs 2>/dev/null || test -d objs gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DPIC -c -o objs/zutil.o zutil.c mv objs/zutil.o zutil.lo gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.5 adler32.lo compress.lo crc32.lo deflate.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo uncompr.lo zutil.lo -lc -L. libz.a rm -f libz.so libz.so.1 ln -s libz.so.1.2.5 libz.so ln -s libz.so.1.2.5 libz.so.1 rmdir objs gcc -O3 -D_LARGEFILE64_SOURCE=1 -o examplesh example.o -L. libz.so.1.2.5 gcc -O3 -D_LARGEFILE64_SOURCE=1 -o minigzipsh minigzip.o -L. libz.so.1.2.5 gcc -O3 -D_LARGEFILE64_SOURCE=1 -o example64 example64.o -L. libz.a gcc -O3 -D_LARGEFILE64_SOURCE=1 -o minigzip64 minigzip64.o -L. libz.a

    Read the article

  • VERBOSE=yes makefile option on gnu make under cygwin not working for me.

    - by goldenmean
    Hi, I use gnumake version GNU Make 3.81 under cygwin on windows. Cygwin version is CYGWIN_NT-6.1-WOW64 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin In my makefile used to build the source, when i say VERBOSE=yes, i still do not see detailed commands and options used to compile,link the code. So basically VEROBSE=yes behaviour seems to be same as VERBOSE=no. Pls. note that the compiler (sparc-elf-gcc) which the make command invokes, is configured with --verbose option. I verified that by checking sparc-elf-gcc -v . Is this switch removed/deprecated for this particular gnumake/cygwin versions or any pointers on how I can see details of the make/compile/link commands. thank you. -AD.

    Read the article

  • How to build this project?

    - by Ali Shafai
    Hi, I've been a visual studio developer for long and just trying to understand how things are in linux/unix worl. I found an open source project (Gcomandos) in source forge and tried to build it. when I download the source, I get these files: 16/02/2007 05:16 PM 25,987 aclocal.m4 16/02/2007 05:17 PM 127,445 configure 16/02/2007 05:16 PM 1,925 configure.ac 17/03/2010 03:48 PM <DIR> gComandos 16/02/2007 05:16 PM 332 gcomandos.pc.in 25/11/2006 10:03 PM 9,233 install-sh 16/02/2007 05:16 PM 353 Makefile.am 16/02/2007 05:17 PM 20,662 Makefile.in 16/02/2007 05:16 PM 1,019 Makefile.include 25/11/2006 10:03 PM 11,014 missing I am now lost. I tried making the .am or the .in files, but GnuMake says there is nothing to make. I tried running the shell scripts, but I got errors. Any guidance appreciated.

    Read the article

  • Makefile trickery using VPATH and include.

    - by roe
    Hi, I'm playing around with make files and the VPATH variable. Basically, I'm grabbing source files from a few different places (specified by the VPATH), and compile them into the current directory using simply a list of .o-files that I want. So far so good, now I'm generating dependency information into a file called '.depend' and including that. Gnumake will attempt to use the rules defined so far to create the included file if it doesn't exist, so that's ok. Basically, my makefile looks like this. VPATH=A/source:B/source:C/source objects=first.o second.o third.o executable: $(objects) .depend: $(objects:.o=.c) $(CC) -MM $^ > $@ include .depend Now for the real question, can I suppress the generation of the .depend file in any way? I'm currently working in a clearcase environment - sloooow, so I'd prefer to have it a bit more under control when to update the dependency information. It's more or less an academic exercise as I could just wrap the thing in a script which is touching the .depend file before executing make (thus making it more recent than any source file), but it'd interesting to know if I can somehow suppress it using 'pure' make. I cannot remove the dependency to the source files (i.e. using simply .depend:), as I'm depending on the $^ variable to do the VPATH resolution for me. If there'd be any way to only update dependencies as a result of updated #include directives, that'd be even better of course.. But I'm not holding my breath for that one.. :)

    Read the article

  • GNU Make: How to call $(wildcard) within $(eval)

    - by bengineerd
    I'm trying to create a generic build template for my Makefiles, kind of like they discuss in the eval documentation. I can't seem to get the wildcard function to work within an eval. The basic code I'm having issues with looks like this. SRC_DIR = ./src/ PROG_NAME = test define PROGRAM_template $(1)_SRC_DIR = $(join $(SRC_DIR), $(1)/) $(1)_SRC_FILES = $(wildcard $$($(1)_SRC_DIR)*.c) endef $(eval $(call PROGRAM_template, $(PROG_NAME))) all: @echo $(test_SRC_DIR) @echo $(test_SRC_FILES) @echo $(wildcard $(wildcard $(test_SRC_DIR)*.c) When I run make with this, the output is ./src/test [correct list of all .c files in ./src/test/] Basically, the wildcard call within PROGRAM_template is not being eval'd as I expect it. The call results in an empty list. The join call is being eval'd correctly though. So, what am I doing wrong? My guess is that $$($(1)_SRC_DIR) is not correct, but I can't figure out the right way to do it. EDIT Once this was solved, it didn't take long for me to hit another issue with eval. I posted it as a new question at http://stackoverflow.com/questions/2428506/workaround-for-gnu-make-3-80-eval-bug

    Read the article

  • How to strip out a -D for just one file in a gnu makefile?

    - by WilliamKF
    I have '-Wredundant-decls' in my CXXFLAGS but for one file, I want it removed. In my GNU makefile, how can I structure a rule to remove just that part of the CXXFLAGS. I know how to add only for that file, I would do something like this: $O/just_one_file.o: CXXFLAGS += -Wredundant-decls So, ideally I'd do something like this (which doesn't work) to remove it: $O/just_one_file.o: CXXFLAGS -= -Wredundant-decls However, maybe with some $ magic, I can construct some kind of sed or perl script to strip out the -Wredundant-decls and set CXXFLAGS to the stripped value: $O/just_one_file.o: CXXFLAGS = $(shell strip magic here for $CXXFLAGS)

    Read the article

  • Workaround for GNU Make 3.80 eval bug

    - by bengineerd
    I'm trying to create a generic build template for my Makefiles, kind of like they discuss in the eval documentation. I've run into a known bug with GNU Make 3.80. When $(eval) evaluates a line that is over 193 characters, Make crashes with a "Virtual Memory Exhausted" error. The code I have that causes the issue looks like this. SRC_DIR = ./src/ PROG_NAME = test define PROGRAM_template $(1)_SRC_DIR = $$(SRC_DIR)$(1)/ $(1)_SRC_FILES = $$(wildcard $$($(1)_SRC_DIR)*.c) $(1)_OBJ_FILES = $$($(1)_SRC_FILES):.c=.o) $$($(1)_OBJ_FILES) : $$($(1)_SRC_FILES) # This is the problem line endef $(eval $(call PROGRAM_template,$(PROG_NAME))) When I run this Makefile, I get gmake: *** virtual memory exhausted. Stop. The expected output is that all .c files in ./src/test/ get compiled into .o files (via an implicit rule). The problem is that $$($(1)_SRC_FILES) and $$($(1)_OBJ_FILES) are together over 193 characters long (if there are enough source files). I have tried running the make file on a directory where there is only 2 .c files, and it works fine. It's only when there are many .c files in the SRC directory that I get the error. I know that GNU Make 3.81 fixes this bug. Unfortunately I do not have the authority or ability to install the newer version on the system I'm working on. I'm stuck with 3.80. So, is there some workaround? Maybe split $$($(1)_SRC_FILES) up and declare each dependency individually within the eval?

    Read the article

  • How to make automake less ugly?

    - by Brendan Long
    I recently learned how to use automake, and I'm somewhat annoyed that my compile commands went from a bunch of: g++ -O2 -Wall -c fileName.cpp To a bunch of: depbase=`echo src/Unit.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I./src -g -O2 -MT src/Unit.o -MD -MP -MF $depbase.Tpo -c -o src/Unit.o src/Unit.cpp &&\ mv -f $depbase.Tpo $depbase.Po Is there any way to clean this up? I can usually easily pick out warning messages, but now the wall of text to read though is 3x bigger and much weirder. I know what my flags are, so making it just says "Compiling xxx.cpp" for each file would be perfect.

    Read the article

  • GNU make: should -j equal number the number of CPU cores in a system?

    - by Johan
    Hi What is you experience with the make -j flag? There seem to be some controversial if the jobs are supposed to be equal to the numbers of cores, or if you can maximize the build by adding one extra job that can be cued up while the others "work". The question is if it is better to use -j4 or -j5? And have you seen (or done) any benchmarking that support one or the other? Thanks Johan

    Read the article

  • Skip makefile dependency generation for certain targets (e.g. `clean`)

    - by Shtééf
    I have several C and C++ projects that all follow a basic structure I've been using for a while now. My source files go in src/*.c, intermediate files in obj/*.[do], and the actual executable in the top level directory. My makefiles follow roughly this template: # The final executable TARGET := something # Source files (without src/) INPUTS := foo.c bar.c baz.c # OBJECTS will contain: obj/foo.o obj/bar.o obj/baz.o OBJECTS := $(INPUTS:%.cpp=obj/%.o) # DEPFILES will contain: obj/foo.d obj/bar.d obj/baz.d DEPFILES := $(OBJECTS:%.o=%.d) all: $(TARGET) obj/%.o: src/%.cpp $(CC) $(CFLAGS) -c -o $@ $< obj/%.d: src/%.cpp $(CC) $(CFLAGS) -M -MF $@ -MT $(@:%.d=%.o) $< $(TARGET): $(OBJECTS) $(LD) $(LDFLAGS) -o $@ $(OBJECTS) .PHONY: clean clean: -rm -f $(OBJECTS) $(DEPFILES) $(RPOFILES) $(TARGET) -include $(DEPFILES) Now I'm at the point where I'm packaging this for a Debian system. I'm using debuild to build the Debian source package, and pbuilder to build the binary package. The debuild step only has to execute the clean target, but even this causes the dependency files to be generated and included. In short, my question is really: Can I somehow prevent make from generating dependencies when all I want is to run the clean target?

    Read the article

  • Using target-specific variable in makefile

    - by James Johnston
    I have the following makefile: OUTPUTDIR = build all: v12target v13target v12target: INTDIR = v12 v12target: DoV12.avrcommontargets v13target: INTDIR = v13 v13target: DoV13.avrcommontargets %.avrcommontargets: $(OUTPUTDIR)/%.elf @true $(OUTPUTDIR)/%.elf: $(OUTPUTDIR)/$(INTDIR)/main.o @echo TODO build ELF file from object file: destination $@, source $^ @echo Compiled elf file for $(INTDIR) > $@ $(OUTPUTDIR)/$(INTDIR)/%.o: %.c @echo TODO call GCC to compile C file: destination $@, source $< @echo Compiled object file for $<, revision $(INTDIR) > $@ $(shell rm -rf $(OUTPUTDIR)) $(shell mkdir -p $(OUTPUTDIR)/v12 2> /dev/null) $(shell mkdir -p $(OUTPUTDIR)/v13 2> /dev/null) .SECONDARY: The idea is that there are several different code configurations that need to be compiled from the same source code. The "all" target depends on v12target and v13 target, which set a number of variables for that particular build. It also depends on an "avrcommontargets" pattern, which defines how to actually do the compiling. avrcommontargets then depends on the ELF file, which in turn depends on object files, which are built from the C source code. Each compiled C file results in an object file (*.o). Since each configuration (v12, v13, etc.) results in a different output, the C file needs to be built several times with the output placed in different subdirectories. For example, "build/v12/main.o", "build/v13/main.o", etc. Sample output: TODO call GCC to compile C file: destination build//main.o, source main.c TODO build ELF file from object file: destination build/DoV12.elf, source build//main.o TODO build ELF file from object file: destination build/DoV13.elf, source build//main.o The problem is that the object file isn't going into the correct subdirectory. For example, "build//main.o" instead of "build/v12/main.o". That then prevents the main.o from being correctly rebuilt to generate the v13 version of main.o. I'm guessing the issue is that $(INTDIR) is a target specific variable, and perhaps this can't be used in the pattern targets I defined for %.elf and %.o. The correct output would be: TODO call GCC to compile C file: destination build/v12/main.o, source main.c TODO build ELF file from object file: destination build/DoV12.elf, source build/v12/main.o TODO call GCC to compile C file: destination build/v13/main.o, source main.c TODO build ELF file from object file: destination build/DoV13.elf, source build/v13/main.o What do I need to do to adjust this makefile so that it generates the correct output?

    Read the article

  • gnu make installed with OS language

    - by Gauthier
    I installed the latest GNU make to my windows machine. The installer decided to setup the language as the OS language, which I did not get prompted for. I want it to be english. My OS is in swedish. I remember I had similar problem with another GNU program (can't recall which), which was solved by adding the env var "lang" with value "c". How can I switch the language of GNU make to english?

    Read the article

  • Recursive wildcards in GNU make?

    - by Roger Lipscombe
    It's been a while since I've used make, so bear with me... I've got a directory, flac, containing .FLAC files. I've got a corresponding directory, mp3 containing MP3 files. If a FLAC file is newer than the corresponding MP3 file (or the corresponding MP3 file doesn't exist), then I want to run a bunch of commands to convert the FLAC file to an MP3 file, and copy the tags across. The kicker: I need to search the flac directory recursively, and create corresponding subdirectories in the mp3 directory. And I want to use make to drive this.

    Read the article

  • Qt4 book says "make release", reality disagrees

    - by DarenW
    Writing some simple Qt4 demos depending the book by Daniel Molkentin. In that book, it says you build the release or debug versions of your app with "make release" or "make debug". In real life, these give errors. Only bare naked "make" works. I assume something has changed between the version of Qt4 used in the book and the version I'm using, qt4.6.2. So what is the proper way to determine whether to make release or debug? (And why can't google find any updates or errata for this book relating to this?)

    Read the article

  • How to get absolute paths after vpath matching in make?

    - by Honza
    I have a makefile that depending on some properties sets vpath and generates a list of source files into one variable. I need to run the makefile without compiling anything (the compilation is actually handled by a different makefile) and just see to which real files the filenames get matched depending on the vpath settings.

    Read the article

  • Makefile generic pattern rule -- xyzzy-en_US.ext2 from xyzzy.ext0

    - by Janne Savukoski
    I can't figure out a way to define a generic pattern rule for the following kind of production with make: require xyzzy-en_US.ext2 from xyzzy.ext0 via xyzzy.ext1. This works: all: xyzzy-en_US.ext2 # to be compiled from xyzzy.ext0 %.ext1 : %.ext0 # produce xyzzy.ext1 %-en_US.ext2 : %.ext1 # produce xyzzy-en_US.ext2 But how to generalize the locale part of the second rule? Or do I need to generate rules for all different locales? Neither of these work: %-??_??.ext2 : %.ext1 # ... %.ext2 : $(@,%-??_??.ext2,%.ext1) # ...

    Read the article

  • Makefile and rm -f file.{ext1,ext2,ext3} issue

    - by ak91
    Hello, Could you explain me, why Makefile rule: clean: rm -f foo.{bar1,bar2,bar3} does not result in removing files: foo.bar1 foo.bar2 and foo.bar3? I believe I saw pattern like that many times in various Makefiles, but I'm currently writing my own Makefile and can't make that rule work correctly (no files are removed). I'm using: gnu make 3.81 gnu bash 4.1.5 Bash evals that pattern as I suspect: $ echo test.{a,b,c} test.a test.b test.c Thanks!

    Read the article

  • GNU Make - Dependencies on non program code

    - by Tim Post
    A requirement for a program I am writing is that it must be able to trust a configuration file. To accomplish this, I am using several kinds of hashing algorithms to generate a hash of the file at compile time, this produces a header with the hashes as constants. Dependencies for this are pretty straight forward, my program depends on config_hash.h, which has a target that produces it. The makefile looks something like this : config_hash.h: $(SH) genhash config/config_file.cfg > $(srcdir)/config_hash.h $(PROGRAM): config_hash.h $(PROGRAM_DEPS) $(CC) ... ... ... I'm using the -M option to gcc, which is great for dealing with dependencies. If my header changes, my program is rebuilt. My problem is, I need to be able to tell if the config file has changed, so that config_hash.h is re-generated. I'm not quite sure how explain that kind of dependency to GNU make. I've tried listing config/config_file.cfg as a dependency for config_hash.h, and providing a .PHONY target for config_file.cfg without success. Obviously, I can't rely on the -M switch to gcc to help me here, since the config file is not a part of any object code. Any suggestions? Unfortunately, I can't post much of the Makefile, or I would have just posted the whole thing.

    Read the article

  • List goals/targets in GNU make

    - by BitShifter
    I have a fairly large makefile that creates a number of targets on the fly by computing names from variables. (eg foo$(VAR) : $(PREREQS)). Is there any way that gnu make can be convinced to spit out a list of targets after it has expanded these variables?

    Read the article

  • Re-execute target when specified as dependency to multiple rules

    - by andrew
    I have the following GNU makefile: .PHONY a b c d a: b c b: d c: d d: echo HI I would like the target 'd' to be run twice -- since it is specified as a dependency by both b & c. Unfortunately, the target 'd' will be executed only once. The output of running make will simply be 'HI', instead of 'HI HI'. How can I fix this? Thanks! To Clarify, the goal is something like this: subdirs = a b c build: x y x: target=build x: $(subdirs) y: target=prepare y: $(subdirs) $(subdirs): $(make) -f $@/makefile $(target)

    Read the article

1 2  | Next Page >