Search Results

Search found 10 results on 1 pages for 'gnumakefile'.

Page 1/1 | 1 

  • How can invoke a shell to make a new environment to run a make inside another make?

    - by WilliamKF
    I would like in my GNUmakefile to have a target rule that invokes a new shell and then with the clean slate of the new shell invokes a new make. What is the syntax to do this? I tried this but it didn't work: .PHONY: setup setup: shell cd myDir; make; cd .. It gets infinite repeat of the following error: make[1]: Entering directory `/disk4/home/user/parent' shell cd myDir; make; cd .. /bin/sh: shell: command not found make[1]: Entering directory `/disk4/home/user/parent' shell cd myDir; make; cd .. /bin/sh: shell: command not found [...]

    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

  • GNUStep make with a precompiled (and prefixed) .pch header from Xcode project?

    - by d11wtq
    I'm trying to build an Xcode project with GNUStep-make. Right now the project is very small (3 classes) however it will grow to hundreds of classes over the coming weeks so I'm trying to get everything figured out and well-organised now. Xcode creates a ProjectName_Prefix.pch file which is a header that: a) get precompiled and b) is prefixed to every file in my project; at least if I understand correctly. Now, how do I tell GNUStep-make what to do with this file when it builds? I've added it to the XXX_PRECOMPILED_HEADERS variable. Cioccolata_OBJC_PRECOMPILED_HEADERS = Cioccolata_Prefix.pch With this in place the build fails with the error: Making all for framework Cioccolata... make[1]: *** No rule to make target `/Users/chris/Projects/Mac/Cioccolata/build/GNUStep/obj/PrecompiledHeaders/ObjC/Cioccolata_Prefix.pch', needed by `internal-precompile-headers'. Stop. make: *** [Cioccolata.all.framework.variables] Error 2 I've also got the following in my makefile: ADDITIONAL_OBJC_FLAGS += -include Cioccolata_Prefix.pch -Winvalid-pch I'm not sure what I've done wrong here. I basically have tried to follow the GNUStep documentation for precompiled headers. None of my project's source files expressly include the Foundation framework since this header does that.

    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

  • 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

  • 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

  • Build an Xcode project on a Linux machine

    - by d11wtq
    Without writing a GNUmakefile by hand, do any tools exist that understand Xcode projects and can build then directly against GNUstep, thus simplifying (slightly) the work required to keep projects functional under Cocoa/Mac and GNUstep/Linux? Basically, is there an xcodebuild style app for Linux? I looked at pbtomake a few weeks ago but it seems to be a dead project.

    Read the article

  • sudo make install: permission denied

    - by Wojtek Rzepala
    I have a most annoying question about building from sources. I've searched for an answer for a long while and nowhere can I find one... I've compiled software from sources before and this just baffled me. So I am trying to install python 2.7.2 from sources. I can do a successful ./configure, also make seems to run fine. But when I do sudo make install, I get a variety of errors... First, sudo make install gives me this: make: stat: GNUmakefile: Permission denied make: stat: makefile: Permission denied make: stat: Makefile: Permission denied make: stat: install: Permission denied make: *** No rule to make target `install'. Stop. So I did chmod +rx Makefile*. To no avail. Then, sudo ls . says ls: cannot access .: Permission denied Then ls -d . says the permissions are drwxr-x--- Then, as a desperate measure, chmod +rx .. That gave me: make: stat: Modules/config.c.in: Permission denied make: *** No rule to make target `Modules/config.c.in', needed by `Makefile'. Stop. So some progress... What is happening here? It looks like some sort of permission problem. I presumed that sudo would be the solution but clearly there is something else going on here... I tried sudo -s but I get those permission problems all over again... I am using Ubuntu 10.04LTS.

    Read the article

  • Compiling Objective-C project on Linux (Ubuntu)

    - by Alex
    How to make an Objective-C project work on Ubuntu? My files are: Fraction.h #import <Foundation/NSObject.h> @interface Fraction: NSObject { int numerator; int denominator; } -(void) print; -(void) setNumerator: (int) n; -(void) setDenominator: (int) d; -(int) numerator; -(int) denominator; @end Fraction.m #import "Fraction.h" #import <stdio.h> @implementation Fraction -(void) print { printf( "%i/%i", numerator, denominator ); } -(void) setNumerator: (int) n { numerator = n; } -(void) setDenominator: (int) d { denominator = d; } -(int) denominator { return denominator; } -(int) numerator { return numerator; } @end main.m #import <stdio.h> #import "Fraction.h" int main( int argc, const char *argv[] ) { // create a new instance Fraction *frac = [[Fraction alloc] init]; // set the values [frac setNumerator: 1]; [frac setDenominator: 3]; // print it printf( "The fraction is: " ); [frac print]; printf( "\n" ); // free memory [frac release]; return 0; } I've tried two approaches to compile it: Pure gcc: $ sudo apt-get install gobjc gnustep gnustep-devel $ gcc `gnustep-config --objc-flags` -o main main.m -lobjc -lgnustep-base /tmp/ccIQKhfH.o:(.data.rel+0x0): undefined reference to `__objc_class_name_Fraction' I created a GNUmakefile Makefile: include ${GNUSTEP_MAKEFILES}/common.make TOOL_NAME = main main_OBJC_FILES = main.m include ${GNUSTEP_MAKEFILES}/tool.make ... and ran: $ source /usr/share/GNUstep/Makefiles/GNUstep.sh $ make Making all for tool main... Linking tool main ... ./obj/main.o:(.data.rel+0x0): undefined reference to `__objc_class_name_Fraction' So in both cases compiler gets stuck at undefined reference to `__objc_class_name_Fraction' Do you have and idea how to resolve this issue?

    Read the article

1