최근에 리눅스 커널 2.6.18 부터 #include 대신 -include config.h 를 사용하기 시작했습니다.
아무리 생각해봐도 마땅한 이유가 생각나지는 않고,
그저 소스에서 한 줄을 줄이려는 목적이 아닌가 생각됩니다.
커널 소스 전체적으로 수천에서 수만 바이트의 용량이 줄어드는 효과가 있겠지요.
어차피 리눅스 커널은 gcc 아닌 다른 컴파일러로 컴파일하기가 불가능에 가까우므로...
질문자의 목적이 소스코드 용량을 줄이려는 목적이 아니라면,
위의 방법이 바른 길이라 생각됩니다.
실제로 저도 저렇게 사용합니다.
하지만, 제가 보기엔...
기존의 소스 덩어리를 수정하지 않고 뭔가를 간단히 바꿔보기 위한 방법을 찾고 계신 것 같습니다.
> 최근에 리눅스 커널 2.6.18 부터 #include 대신 -include config.h 를 사용하기 시작했습니다.
> 아무리 생각해봐도 마땅한 이유가 생각나지는 않고,
> 그저 소스에서 한 줄을 줄이려는 목적이 아닌가 생각됩니다.
> 커널 소스 전체적으로 수천에서 수만 바이트의 용량이 줄어드는 효과가 있겠지요.
> 어차피 리눅스 커널은 gcc 아닌 다른 컴파일러로 컴파일하기가 불가능에 가까우므로...
>
불필요한 매크로명 예약도 피하고 귀차니즘도 만족하기
위해서가 아닐까요? :-)
> 질문자의 목적이 소스코드 용량을 줄이려는 목적이 아니라면,
> 위의 방법이 바른 길이라 생각됩니다.
> 실제로 저도 저렇게 사용합니다.
>
> 하지만, 제가 보기엔...
> 기존의 소스 덩어리를 수정하지 않고 뭔가를 간단히 바꿔보기 위한 방법을 찾고 계신 것 같습니다.
>
소스를 일절 수정하지 않고 파일만 #include 해서 의미있는 결과를 얻어
내기란 쉽지 않습니다. :-)
단지
#include 매크로명
의 형태가 표준에 새로 추가된 이유가 "바로" 원 질문자가 질문하신
상황이기에 이런 방법도 있을 수 있음을 보였습니다 - 메뉴는 펼쳐져 있고
맘에 드는 것 골라서 드시면 되겠네요.
한가지 유의할 점은 -include 의 경우 옵션을 통해 #include 되는 파일이
삽입되는 위치가 일반적인 #include 문을 사용하는 위치가 다소 다릅니다.
보통 코드 상에서는 표준 헤더, 그 외 준표준 헤더, 사용자 헤더의 순으로
#include 합니다만, -include 옵션은 무조건 해당 파일의 가장 처음에
#include 되는 것으로 처리합니다.
또한, 파일을 찾는 경로 역시 (일반적인 #include "file.h" 형태처럼)
컴파일 되는 소스 파일의 디렉토리부터가 아니라 전처리기 작업 디렉토리
부터 찾게 됩니다.
"-include 파일명"
"-include 파일명" 옵션이 아닐까요?(확인은 해보지 않았습니다.)
> 지금 어떤
> 지금 어떤 프로그램을 컴파일 하고 있는데
> 소스를 고치는 방법말고
> gcc 로 컴파일 할때 특정 헤더파일을 gcc의 인자로 넘겨서 헤더파일을 포함하게끔 할수 없을지..
>
-include 옵션도 가능합니다만, 소스 내 include 되는 위치나
경로 문제를 고민하고 싶지 않다면 다음 방법도 쓸만 합니다.
(더구나 이식성도 있군요!! ㅋ)
그리고, gcc 실행시에는
와 같이 해줍니다. INCLUDE_FILE 을 따로 정의해주지 않으면
"default.h" 가 #include 됩니다.
gcc 실행시 쌍따옴표를 escape 하는 것이 맘에 안드신다면
그리고
로 해줄 수도 있습니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
최근에 리눅스 커널
최근에 리눅스 커널 2.6.18 부터 #include 대신 -include config.h 를 사용하기 시작했습니다.
아무리 생각해봐도 마땅한 이유가 생각나지는 않고,
그저 소스에서 한 줄을 줄이려는 목적이 아닌가 생각됩니다.
커널 소스 전체적으로 수천에서 수만 바이트의 용량이 줄어드는 효과가 있겠지요.
어차피 리눅스 커널은 gcc 아닌 다른 컴파일러로 컴파일하기가 불가능에 가까우므로...
질문자의 목적이 소스코드 용량을 줄이려는 목적이 아니라면,
위의 방법이 바른 길이라 생각됩니다.
실제로 저도 저렇게 사용합니다.
하지만, 제가 보기엔...
기존의 소스 덩어리를 수정하지 않고 뭔가를 간단히 바꿔보기 위한 방법을 찾고 계신 것 같습니다.
> 최근에 리눅스 커널
> 최근에 리눅스 커널 2.6.18 부터 #include 대신 -include config.h 를 사용하기 시작했습니다.
> 아무리 생각해봐도 마땅한 이유가 생각나지는 않고,
> 그저 소스에서 한 줄을 줄이려는 목적이 아닌가 생각됩니다.
> 커널 소스 전체적으로 수천에서 수만 바이트의 용량이 줄어드는 효과가 있겠지요.
> 어차피 리눅스 커널은 gcc 아닌 다른 컴파일러로 컴파일하기가 불가능에 가까우므로...
>
불필요한 매크로명 예약도 피하고 귀차니즘도 만족하기
위해서가 아닐까요? :-)
> 질문자의 목적이 소스코드 용량을 줄이려는 목적이 아니라면,
> 위의 방법이 바른 길이라 생각됩니다.
> 실제로 저도 저렇게 사용합니다.
>
> 하지만, 제가 보기엔...
> 기존의 소스 덩어리를 수정하지 않고 뭔가를 간단히 바꿔보기 위한 방법을 찾고 계신 것 같습니다.
>
소스를 일절 수정하지 않고 파일만 #include 해서 의미있는 결과를 얻어
내기란 쉽지 않습니다. :-)
단지
의 형태가 표준에 새로 추가된 이유가 "바로" 원 질문자가 질문하신
상황이기에 이런 방법도 있을 수 있음을 보였습니다 - 메뉴는 펼쳐져 있고
맘에 드는 것 골라서 드시면 되겠네요.
한가지 유의할 점은 -include 의 경우 옵션을 통해 #include 되는 파일이
삽입되는 위치가 일반적인 #include 문을 사용하는 위치가 다소 다릅니다.
보통 코드 상에서는 표준 헤더, 그 외 준표준 헤더, 사용자 헤더의 순으로
#include 합니다만, -include 옵션은 무조건 해당 파일의 가장 처음에
#include 되는 것으로 처리합니다.
또한, 파일을 찾는 경로 역시 (일반적인 #include "file.h" 형태처럼)
컴파일 되는 소스 파일의 디렉토리부터가 아니라 전처리기 작업 디렉토리
부터 찾게 됩니다.
그와 같은 차이만 염두에 두신다면 용도에 맞춰 사용하시는데 아무 문제가
없습니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
[bushi@rose ~]$[bushi@rose
특정헤더 파일의 내용치환법
특정 헤더 파일의 내용을 치환하는 방법도 있지 않을까 생각합니다.
하지만, 썩 좋아 보이지는 않습니다.
이미 첨부된 헤더를 대체하시려면
원래의 소스를 터치하실수 없는 경우에 많이 쓰는데요,
콤파일 하실때 새로운 디렉토리를 제일 처음 include 디렉토리로 정의해 두세요.
ex) gcc -I/home/me/include_override ...
그리곤 그 디렉토리에 소프트 링크를 생성하시면 됩니다.
예를 들어 소스에서 foo.h를 대체하시려면
ln -s [path_to_new_header] /home/me/include_override/foo.h
이렇게 하시면 되죠.
댓글 달기