아래 명령어로 C 소스코드를 컴파일 할 수 있다. (파일 이름은 본인 파일에 맞게) gcc -o Hello.exe Hello.c -> 그냥 gcc 파일명 해도 컴파일은 된다. 그러면 결과가 a.out으로 나오는데, 위 명령어는 -o 옵션을 통해 이름을 Hello.exe로 바꾸라고 한 것이다. 컴파일 방식은 어떠한 것인가? 소스파일이 있으면 그걸 실행파일(기계어)로 변환한다. 다르게 말하면 이진 바이너리 코드로 바꾼다. *정확히는 대부분 어셈블리어로 변환하고, 다시 어셈블리어를 기계어로 변환한다. 무엇이 바꿔주는가? 컴파일러가 바꿔준다. 실행파일은 기계어이므로 바로 실행된다. 그래서 인터프리트 방식이나 하이브리드 방식보다 빠르다. 실행하려면 해당 실행파일의 이름을 알려주면 된다. 윈도우는 그냥 이름+확장자..
인터프리트 방식은 보통 컴파일 방식과 비교된다. 기계어가 아니면 CPU가 이해를 못하니 소스파일을 한번에 전부 어셈블리어로 바꾸고 그걸 기계어로 다 바꿔서 실행하는 게 컴파일 방식이다. 인터프리트 방식은 다르다. 소스파일을 일단 읽고 문법검사를 한 다음에 해석한다. 그리고 인터프리터가 해당 해석 결과를 통해 OS가 실행하도록 한다. 인터프리트 방식을 쓰는 언어는 대표적으로 자바스크립트와 파이썬이 있다. 자바스크립트를 node.js를 통해 인터프리트 방식으로 실행해보자. node.js 를 설치한다. $node 파일명.js 를 통해서 소스코드를 실행한다. 인터프리트 방식은 특징이 있다. 소스파일을 바로 컴파일하는 게 아니라 직접 읽는다. 실행할 때 소스코드가 필요하다. (컴파일 방식은 컴파일된 결과인 어셈블..
컴파일러, JVM버전과 클래스 파일(바이트코드)에 대한 이야기로 시작헤보자. JVM은 Bytecode 실행에 대하여 하위호환성을 보장한다. 높은 버전의 JVM은 낮은 버전의 컴파일러가 생성한 바이트코드는 실행할 수 있다. 그러나 낮은 버전의 JVM은 자기보다 높은 버전의 컴파일러가 생성한 바이트코드는 실행할 수 없다. *컴파일 시 호환되는 JVM의 버전을 하위버전도 호환되도록 설정해주어야 한다. *컴파일 시 같은 버전의 JVM만 호환되도록 설정할 수도 있다. 그러면 버전관리를 할 때, java 소스파일을 컴파일 한 .class 파일을 보관해야 하는지 의문이 생긴다. 버전 관리 시스템의 관리 대상을 생각해보자. 아래의 항목들은 버전 관리 시스템에서 관리해줘야 하는 대상일까? 소스파일 문서 설정파일 개발도구..
충돌이 뭐요? 버전관리 시스템에서 충돌이란 무엇이고 언제 발생할까? 충돌은 부딪히는 걸 말하는데, 깃에서는 로컬 리포지토리 => 리모트 리포지토리로 Push 하는 내용이 겹치는 것을 말한다. 두 개발자가 같은 파일에 대해서, 같은 버전에 대해 다른 작업을 해서 둘 다 서버에 Push 하려고 할 때 충돌이 발생한다. 깃 서버는 늦게 보낸 쪽의 Push를 거절한다. (reject) 혼자서도 의도적으로 충돌을 일으켜서 해결 실습을 해볼 수 있다. 리모트 리포지토리를 로컬에 두 개를 clone 한다. 그리고 같은 파일에 대해서 수정한 후 add >> commit >> push 해보면 된다. 그러면 늦게 한 쪽의 push가 reject 된다. 충돌은 어떻게 해결하는가? 방식은 한가지가 아니나 Merge 방식을 가..
