• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Using custom build rules
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using custom build rules


  • Subject: Re: Using custom build rules
  • From: Mark Lentczner <email@hidden>
  • Date: Fri, 31 Dec 2004 13:07:09 -0800

On Dec 30, 2004, at 9:47 AM, Tommy Nordgren wrote:
I have a compiler project that uses XCode. I need to run an external tool (antlr) on a parser generator source file. I've specified a build rule for antlr source files (*.g), but for some reason the tool don't get called. What can be causing this, and how do I fix this?

See my post about building Antlr grammars to the mailing list last March:
http://lists.apple.com/archives/xcode-users/2004/Mar/msg00334.html


Short answer is that if your Antlr .g files don't have any dependencies on each other (such as shared Token vocabularies), then you can get a custom rule to work. On the other hand, if there is a dependency of one .g file on another (say MyParser.g requires that MyLexer.g get Antlr'd first so it can use MyLexerTokenTypes.txt and MyLexerTokenTypes.h), then the custom rule facility isn't robust enough to support it.

My current solution involves having a separate target for the grammars, and then make my main target depend on this target. This ensures that the grammar target gets built first. The grammar target is just a shell script target, and the single script phase is just:
cd grammar
make ${ACTION}
Note that there are no inputs or outputs set on this script.


The makefile in grammar (where my .g files are and where the .cpp, etc. files get built) is:
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
ANTLR = /usr/local/bin/antlr


GRAMMARS = ScriptParser.g ScriptLexer.g ScriptCompiler.g
CPP_FILES = $(patsubst %.g, %.cpp, $(GRAMMARS))
HPP_FILES = $(patsubst %.g, %.hpp, $(GRAMMARS))
TOKEN_HPP_FILES = $(patsubst %.g, %TokenTypes.hpp, $(GRAMMARS))
TOKEN_TXT_FILES = $(patsubst %.g, %TokenTypes.txt, $(GRAMMARS))

all: $(CPP_FILES) $(HPP_FILES) $(TOKEN_HPP_FILES)
build: all

ScriptLexer.cpp :      ScriptParserTokenTypes.txt
ScriptCompiler.cpp :   ScriptParserTokenTypes.txt

%.cpp %.hpp %TokenTypes.hpp %TokenTypes.txt: %.g
	$(ANTLR) $<
	@touch $*.cpp $*.hpp $*TokenTypes.hpp $*TokenTypes.txt

clean:
rm -f $(CPP_FILES)
rm -f $(HPP_FILES)
rm -f $(TOKEN_HPP_FILES)
rm -f $(TOKEN_TXT_FILES)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Note that I express the dependency that two .g files have on the third by expressing that building the .cpp file depends on the third's TokenTypes.txt file.


There are some problems with this approach: Clean doesn't work because, alas, XCode doesn't invoke the script for a clean operation (even though the makefile, and the way the script is written, could handle it).

I think about improving this by perhaps having the makefile build the intermediates in the location passed in by XCode (in the environment variable DERIVED_FILES_DIR), though I haven't explored how well that plays with adding those derived sources as inputs in the main target. But I think these would get cleaned by Xcode on a Clean operation...

I also don't know if there would be any advantage to putting listing the inputs and outputs in the script phase. (See my earlier post for woes with these). It might cause Xcode to not run the script and hence the makefile on every build, if not needed... but the makefile is quick and won't touch anything if nothing needs to be built.

	- Mark

Mark Lentczner
email@hidden
http://www.wheatfarm.org/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Using custom build rules (From: Tommy Nordgren <email@hidden>)

  • Prev by Date: Re: Localizing Apps-Problem with Foreign chars
  • Next by Date: adding a target to an aggregate
  • Previous by thread: Using custom build rules
  • Next by thread: Re: Using custom build rules
  • Index(es):
    • Date
    • Thread