2012-03-19 4 views
0

.l 파일을 빌드하기 위해 flex를 호출하고, gcc를 호출하여 모든 것을 빌드하고 싶습니다. 메이크 파일에서 flex 호출하기

내가 tryed :

comp: 
    lex scanner.l \ 
    gcc -o a.out main.c hash.c -I. 

에러 :

lex scanner.l \ 
    gcc -o a.out main.c hash.c -I. 
lex: impossible to opne gcc 
/usr/bin/m4:stdin:2994: ERROR: end of file in string 

lex scanner.l 
<tab> gcc -o a.out main.c hash.c -I. 

오류 : 누락 세퍼레이터.

lex.yy.c가 생성하는 lex has는 주 파일에 포함됩니다. 사전에

감사합니다,

페드로

+0

두 번째 예의 _both_ 명령보다 먼저 탭이 필요합니다. –

+0

@Pedro Dusso - 편의상, lex.yy.c를 main.c에 포함시키고 있습니까? extern 선언이나 다른 이유를 쓰지 않아도됩니다. lex.yy.c 파일은 main.c에 포함될 필요가 없습니다. – gbulmer

+0

@ gbulmer : 예, 알 수 있습니다. 그러나 scanner.l c 부분에 initMe() 함수를 정의하고 있습니다. 내 main.c는 자동화 된 테스트를위한 일반적인 main.c로 대체 될 것이다. main.c를 scanner.l에 포함시키는 방법은 무엇입니까? 적절한 include를 추가하고 다시 작성 하시겠습니까? –

답변

1
all: a.out 

lex.yy.c: scanner.l 
    lex scanner.l 

a.out: lex.yy.c main.c hash.c 
    gcc -o a.out main.c hash.c -I. 
+0

우리는 미안하다. 괜찮으 시다면, 당신의 대답이 불완전하기 때문에 제 것을 떠날 것입니다. lex.yy.c는 어떤 단계에서 컴파일 될 필요가 있습니다. – gbulmer

1

백 슬래시를 제거하거나 이전에 세미콜론 (;)를 추가합니다.
이제는 두 명령이 한 줄에 함께 추가되어 하나의 긴 명령으로 실행됩니다.

3

이 시도 :

lex.yy.c: scanner.l 
    lex scanner.l 

comp: main.c hash.c 
    gcc -o a.out main.c hash.c -I. 

main.c: lex.yy.c 

첫 번째 규칙 세트는 말한다 makelex.yy를 다시 명령을 언제든지에게 scanner.l 변경을 재 구축 할 필요가 및 제공을 lex.yy.c .c. 두 번째 규칙 세트는 가짜 대상 빌려main.c에되는 hash.c에 따라 달라 make 알려줍니다. 두 파일 중 하나가 변경되면 make comp을 호출하면 다시 컴파일됩니다. 마지막 행은 makemain.c lex.yy.c이 변경 될 때마다 언제든지 더러운 것으로 간주하도록하는 독립 실행 형 종속성입니다. 또한 make comp을 호출하여 lex.yy.c이 없으면이를 만듭니다.

+0

마지막 줄 main.c : lex.yy.c가 잘못되었을 수도 있습니다. main.c에는 보통 lex.yy.c가 포함되지 않습니다. main.c에 포함되어있는 y.tab.h 파일을 생각하고 있습니까? – gbulmer

+0

나는'comp : main.c hash.c' 규칙을 사용하는 이점 (이 경우)이 있다고 생각하지 않는다. 대신 규칙에 따라 프로그램을 만들 수 있으며 모든 소스에 따라 a.out이 달라집니다. – gbulmer

+0

@perreal - 필자는 생각할 필요가 없다. [GNU flex document] (http://flex.sourceforge.net/manual/Introduction.html#Introduction) "flex는 C 소스 파일 인 lex를 출력으로 생성한다. .yy.c는 기본적으로 yylex() 루틴을 정의합니다.이 파일을 컴파일하고 플렉스 런타임 라이브러리와 링크하여 실행 파일을 생성 할 수 있습니다. " main은 yylex()를 호출하면됩니다. – gbulmer

0

IIRC 보통 Makefle 패턴은

이 원래의 코드를 가정 변경 lex.yy.c를 원래의 코드에서, main.c를이 포함되어 있기 때문에이 잘못

a.out: lex.yy.c main.c hash,c 
<tab> gcc -o a.out main.c hash.c lex.yy.c -I. -ll 

lex.yy.c: scanner.l 
<tab> lex scanner.l 

입니다 그래서 main.c는 이 아닙니다.은 lex.yy.c를 포함합니다.

yylex의 두 가지 정의가 있기 때문에 변경하지 않으면 실패합니다()는 main.c에있는 #include에서 하나, 소스 코드 컴파일 단위로 제공되기 때문에 하나입니다. 사람들이 이 아닌 다른 사람에게 .c 파일을 포함하도록을 권장합니다.

일반적으로 고유 한 기호 및 코드를 생성하는 포함 된 소스 파일에는 다른 파일 확장명 (.i)을 사용하는 것이 일반적입니다.

+0

gcc가 동일한 함수의 분리 된 정의를 포함하고있는'main'과'lex.yy'를 링크하려고 할 때 이것이 에러를 일으킬 것이라고 생각합니다. – Beta

+0

@Beta - 당신이 맞습니다. lex.yy.c가 main.c에 포함되어 있다면 yylex에 대한 두 가지 정의가 있습니다. 나는 항상 lex.yy.c를 포함하는 것을 피하고 항상 컴파일하고 링크 만한다. 공유 헤더 파일을 사용하여 유형, 기능 및 공유 데이터를 정의합니다. 프로그램이 발전하면서 소스 코드를 새 파일로 리팩토링하기를 원할 수도 있기 때문에이 방법이 마음에 듭니다. 따라서 공유 기호를 정의하기 위해 명시적인 헤더를 사용하는 것이 장점입니다. 나는 OP가 lex.yy.c를 main.c에 포함시키는 이유를 발견하고 싶다. TBF, 문제가 작 으면 거의 문제지만 내 '반사 신경'은 나를 도왔다. 그래서 나는 이해하기를 좋아한다. – gbulmer

+0

나는 똑같은 본능을 가지고 있으며, OP가 그것을 받아 들여야한다고 생각합니다. 저는 왜 당신의 해결책이 쓰여진 것처럼 그에게 효과가 없을지를 지적하고 있습니다. 한 번에 하나의 장애물. – Beta

관련 문제