• 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: Build phase query--SOLVED
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Build phase query--SOLVED


  • Subject: Re: Build phase query--SOLVED
  • From: Michael McLaughlin <email@hidden>
  • Date: Mon, 01 Sep 2014 18:33:33 -0400

I did have a custom build rule, for all YACC source files, as follows:

# $(YACC)
cd "${INPUT_FILE_DIR}"
/usr/local/bin/bison -d "${INPUT_FILE_NAME}"
mv ${INPUT_FILE_BASE}.tab.c "${DERIVED_FILE_DIR}/${INPUT_FILE_BASE}.tab.c"
mv ${INPUT_FILE_BASE}.tab.h "${DERIVED_FILE_DIR}/${INPUT_FILE_BASE}.tab.h"

$(DERIVED_FILE_DIR)/${INPUT_FILE_BASE}.tab.c   <— Output files
$(DERIVED_FILE_DIR)/${INPUT_FILE_BASE}.tab.h

My /usr/local/bin/bison is version 3.0.2 which is why I needed this custom build rule.

There is no other tab.c file anywhere, just the one created by Bison.   The derived source file is compiled even though it is not part of the target.

When the .y file is in the project, the tab.c file is compiled twice to give two object files (and duplicate symbols).

On Sep 1, 2014, at 5:02 PM, Roland King <email@hidden> wrote:


On 2 Sep 2014, at 12:41 am, Michael McLaughlin <email@hidden> wrote:

This was my mistake.  I did the steps below because adding the tab.c file to the target, for the sake of breakpoints, gave a duplicate-symbols linker error.

I had not realized that breakpoints could be set in a project file even though it was not a target file.  Of course, this still requires a one-time preliminary compilation of the .y file in order to create a tab.c file so that the latter can be added to the project (even if it is subsequently modified).



But why do you get duplicate symbols doing it the way you did it originally? I assume because having xxx.y in the project caused Xcode to create another xxx.c on top of the one you were creating with a rule?

By the way - did you try going to the Build Rules phase of your project and adding a custom rule for .y files, or even just your own single .y file. That should put the whole thing nicely in the workflow without having to add the intermediate.

--
Michael McLaughlin
email@hidden





 _______________________________________________
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: 
 >Re: Build phase query--SOLVED (From: Michael McLaughlin <email@hidden>)

  • Prev by Date: Re: Build phase query--SOLVED
  • Next by Date: Saving state of Schemes in svn repository?
  • Previous by thread: Re: Build phase query--SOLVED
  • Next by thread: Saving state of Schemes in svn repository?
  • Index(es):
    • Date
    • Thread