찾아보면 풀 소스를 받아서 , 이런저런 설정을 하고서 컴파일을 해서 lib를 만드는데요.
이 결과 lib를 각자가 라이브러리 디렉토리에 넣어서 이용하잖아요?
그런데 여기서 궁금한 점이... lib 파일을 공유하는 것이 아니라 왜 이렇게 따로 컴파일을 해서 만든 것을
각자가 이용하는 것인가요? 하드웨어 의존성이 존재하기 때문인가요?
아니면 library 파일의 특성 때문에?
아시는 분은 답변 좀 부탁드립니다.
사용자 라이브러리나 Shared Object를 말씀하시는 건가요?
몸체가 큰 어플 제작시 모듈별로 라이브러리화를 해서 동적으로 필요하게 재배치 되게끔 만든다면 실용적인 면이나 자원 소모적인 면에서 유리하거든요.
통소스로 어플을 만든다면 일부분의 수정사항이 있을때 모두 재컴파일을 해줘야 하는 상황이 발생 하기도 하구요.
모듈별로 쪼개서 라이브러리화 해서 아카이브로 만들어 놓으면 업무적으로 짜임새도 있고(로드맵) 모듈별로 각각 컴파일이 가능하며 메인에서 통으로 매번 컴파일 할 필요도 없습니다.
사람의 신체를 생각하시면 될 듯합니다. 머리/몸체/팔/다리 가 존재하듯이 머리가 main이고 몸체, 팔, 다리 별로 라이브러리화 해서 main 에서 그때그때 필요할 때 동적으로 몸, 팔, 다리를 호출하는 거죠.
그리고 몸체/팔/다리 에 수정사항이 생기면 main에서 통으로 컴파일 할 필요 없이 각 모듈에서만 수정하고 컴파일 해주면 되구요.
제가 東問西答 한건 아닌지 모르겠군요. -------------------------------------------------------------- 가장 나이가 많은 사람은 오래 산 사람이 아니라 많은 경험을 한 사람이다.
가장 나이가 많은 사람은 오래 산 사람이 아니라 많은 경험을 한 사람이다.
예, 제가 궁금한 것은 이러한 모듈에 해당하는 library 들을, 왜 굳이 소스를 다시 받아서 빌드하도록 배포하는 지에 대한 궁금증입니다.
즉, 소스를 다운 받아서 모듈별 build를 거치면 library 들을 얻을 수 있는데요. 처음부터 배포를 컴파일 이후의 library 를 배포하지
않고 소스를 다운받도록 하는 것인지가 궁금하네요. 뭔가 다른 이유가 있으니 당연히 이렇게 하는 것이리라 생각합니다만, 그것이
뭔지 알고 싶어서 이렇게 글을 올렸습니다^^
-_-v
Library 들을 배포하는 경우도 많이 있습니다. 통상 Source도 같이 배포하는 경우 직접 컴파일하는 경우도 많습니다. 또 다른 lib들에 의존이 있는 경우에는 직접 컴파일 해야만하는 경우도 있습니다.
이런 답변이 아니고 혹시 네트웍상의 다중 사용자간의 shared(또는 derived) object를 말씀하시는 것이면 분명히 lib이나 executable 을 공유하도록 하는 방법도 많이들 씁니다.
--
Full Source를 배포하는 것은 대부분이 의존성이 존재하는 프로그램이라서
"풀 소스"를 다운 받아서 직접 컴파일해서 사용하라.. 의 의미를 가진다는 말씀이신가요?
그게 아니라면... 굳이 Full Source를 배포할 필요없이, 받은 사람도 컴파일을 다시 할 필요 없이,
그냥 하나의 라이브러리 파일 자체만 다운받아서 사용하면 되는 것 같아서요.
(굳이 사용자가 재 컴파일을 하게끔 Full Source를 배포하는 의도를 잘 모르겠어서요^^;
그렇다고 100% 전부 의존성이 존재하는 소스들은 또 아닌 것 같기도 하구요.)
아무도 컴파일해서 쓰라고 강제하지 않습니다. 컴파일하는게 좋은 사람은 컴파일해서 쓰고, 그게 싫은 사람은 바이너리를 쓰면되지요. 그렇지 않고 컴파일 하는 경우라면 소스밖에 없기 때문이겠죠.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
사용자 라이브러리나 Shared Object를 말씀하시는 건가요?
사용자 라이브러리나 Shared Object를 말씀하시는 건가요?
몸체가 큰 어플 제작시 모듈별로 라이브러리화를 해서 동적으로 필요하게 재배치 되게끔 만든다면
실용적인 면이나 자원 소모적인 면에서 유리하거든요.
통소스로 어플을 만든다면 일부분의 수정사항이 있을때 모두 재컴파일을 해줘야 하는 상황이 발생
하기도 하구요.
모듈별로 쪼개서 라이브러리화 해서 아카이브로 만들어 놓으면 업무적으로 짜임새도 있고(로드맵)
모듈별로 각각 컴파일이 가능하며 메인에서 통으로 매번 컴파일 할 필요도 없습니다.
사람의 신체를 생각하시면 될 듯합니다. 머리/몸체/팔/다리 가 존재하듯이
머리가 main이고 몸체, 팔, 다리 별로 라이브러리화 해서 main 에서 그때그때 필요할 때 동적으로
몸, 팔, 다리를 호출하는 거죠.
그리고 몸체/팔/다리 에 수정사항이 생기면 main에서 통으로 컴파일 할 필요 없이 각 모듈에서만
수정하고 컴파일 해주면 되구요.
제가 東問西答 한건 아닌지 모르겠군요.
--------------------------------------------------------------
가장 나이가 많은 사람은 오래 산 사람이 아니라 많은 경험을 한 사람이다.
가장 나이가 많은 사람은 오래 산 사람이 아니라 많은 경험을 한 사람이다.
예, 제가 궁금한 것은요^^
예, 제가 궁금한 것은 이러한 모듈에 해당하는 library 들을, 왜 굳이 소스를 다시 받아서 빌드하도록 배포하는 지에 대한 궁금증입니다.
즉, 소스를 다운 받아서 모듈별 build를 거치면 library 들을 얻을 수 있는데요. 처음부터 배포를 컴파일 이후의 library 를 배포하지
않고 소스를 다운받도록 하는 것인지가 궁금하네요. 뭔가 다른 이유가 있으니 당연히 이렇게 하는 것이리라 생각합니다만, 그것이
뭔지 알고 싶어서 이렇게 글을 올렸습니다^^
-_-v
Library 들을 배포하는
Library 들을 배포하는 경우도 많이 있습니다.
통상 Source도 같이 배포하는 경우 직접 컴파일하는 경우도 많습니다.
또 다른 lib들에 의존이 있는 경우에는 직접 컴파일 해야만하는 경우도 있습니다.
이런 답변이 아니고 혹시 네트웍상의 다중 사용자간의 shared(또는 derived) object를 말씀하시는 것이면
분명히 lib이나 executable 을 공유하도록 하는 방법도 많이들 씁니다.
--
--
따라서..
Full Source를 배포하는 것은 대부분이 의존성이 존재하는 프로그램이라서
"풀 소스"를 다운 받아서 직접 컴파일해서 사용하라.. 의 의미를 가진다는 말씀이신가요?
그게 아니라면... 굳이 Full Source를 배포할 필요없이, 받은 사람도 컴파일을 다시 할 필요 없이,
그냥 하나의 라이브러리 파일 자체만 다운받아서 사용하면 되는 것 같아서요.
(굳이 사용자가 재 컴파일을 하게끔 Full Source를 배포하는 의도를 잘 모르겠어서요^^;
그렇다고 100% 전부 의존성이 존재하는 소스들은 또 아닌 것 같기도 하구요.)
-_-v
아무도 컴파일해서
아무도 컴파일해서 쓰라고 강제하지 않습니다.
컴파일하는게 좋은 사람은 컴파일해서 쓰고, 그게 싫은 사람은 바이너리를 쓰면되지요.
그렇지 않고 컴파일 하는 경우라면 소스밖에 없기 때문이겠죠.
댓글 달기