make 명령어

  1. 규모가 큰 프로그램의 컴파일을 위한 유용한 도구

  2. 많은 수의 소스로 구성된 프로그램

  3. 사용자와 시스템에 따라 다양한 컴파일 옵션이 필요한 프로그램

  4. 시스템 설정 구성 - 컴파일 - 설치 등의 일련의 작업이 필요한 경우

  5. make 명령어는 makefile을 이용하여 컴파일 작업을 수행한다.

make [-f makefile이름] [options] [targets]


- 별도의 makefile 파일을 지정하지 않으면 현재 디렉터리의 makefile 혹은 Makefile을 이용한다.

- 타겟을 지정하지 않으면 all 타겟을 빌드한다.



Makefile

  1. 컴파일/빌드 규칙을 기술해 놓은 파일

  2. 컴파일 명령을 비롯한 쉘 명령어로 구성 (쉘 스크립트와 유사하다)

  3. 소스파일들 간의 종속성을 명시

  4. make가 종속성을 자동적으로 파악하여 효율적인 컴파일 작업 수행

  5. 소스파일 하나를 수정하더라도 전부 컴파일할 필요가 없다.

  6. 소스 컴파일 이외의 작업도 기술 가능



Makefile의 기본 구성

1. 타겟(Target)

  • 종속성을 표시하기위해 쉘 명령어를 그룹핑한 것 (종속성 목록은 파일이름들이 나열되어 있다.)

  • 콜론(:)으로 타겟과 종속성 목록을 구분한다. ex) target : test1.o test2.o

  • 쉘 명령어는 항상 [tab] 으로 시작하며, 타겟 다음줄부터 기술한다.

  • 그 타겟의 종속성이 맞을 때만 쉘 명령어가 실행된다. 즉, 파일들이 그 타겟을 구성한다고 생각하면 된다.

  • 종속성 목록에 있는 파일들을 만들기 위해 make 명령어로 컴파일 작업을 수행한다.

  • 종속성 목록 중 하나라도 빠지면 오류 발생


2. 과정(Procedure)

  • 명령행에 지정된 명령을 실행하여 타겟을 빌드

  • 종속성에 지정된 파일이 없으면 해당 빌드 수행

  • 종속성 파일이 갱신되면 타겟을 다시 빌드

  • all과 clean

- all: 모든 빌드 타겟을 종속성 목록에 명시

- clean: make에 의해 생성된 파일들을 삭제


3. 매크로(Macro)

  • 매크로(=변수) 정의 : 매크로 이름 = 값

  • 매크로 사용 : $(매크로이름), ${매크로이름}

  • 주석은 '#'으로 시작한다.

  • 매크로는 항상 맨 위에 기술한다.

  • 기본적인 매크로

- CC : 컴파일러 프로그램 명시

- CFLAGS : 컴파일 옵션 명시



'Note' 카테고리의 다른 글

[GooglePlay] 인앱 결제  (0) 2018.12.29
GDB 사용법  (0) 2018.06.29
GCC 사용법  (0) 2018.06.29
git 명령어 & Bitbucket 사용하기  (0) 2018.06.27
Domain Name System - DNS와 네임서버  (0) 2017.06.20


GCC = GNU C Compiler



1. 주요 옵션

 -g

 디버깅 정보를 포함하여 출력 파일 생성

 -W

 합법적이지만 모호한 코딩에 대해 경고 메시지 출력

 -Wall

 모든 모호한 코딩에 대해 경고 메시지 출력

 -O2

 최적화 수준2 (-O0, -O1, -O3 가능)

 -o  [파일이름]

 출력 실행파일 이름 지정 (옵션이 없으면 a.out으로 생성)


2. 출력 제어 옵션

 -E

 전처리 결과를 화면에 출력

 -S

 컴파일만 수행, *.s 파일 생성

 -c

 컴파일과 어셈블만 수행, *.o 파일 생성

 -v

 컴파일 과정과 각 명령어와 gcc 버전 정보 표시

 -save-temps

 컴파일 중간 파일 생성 (*.i, *.s)



3. 전처리 옵션

-D<Macro>[=value]

 상수 선언(#define), 선택적 컴파일이나 외부 상수 선언에 사용

 -I<dir>

헤더 파일의 검색 경로 추가


4. 최적화 옵션

 -O<숫자>

 숫자가 클수록 최적화 수준 높음

 프로그램의 실행 시간과 크기를 줄이는 최적화

 컴파일 시간이 증가하고, 안전성에 문제 가능성 있음.

 -Os

 프로그램 크기를 줄이는 최적화

 -march=<CPU>

 특정 CPU에 최적화된 코드 생성



5. 링킹 옵션

 -l<library>

 링킹 라이브러리 지정

 -L<dir>

 라이브러리 검색 경로 추가

 -static

 정적 라이브러리로 링킹 수행

 디버깅 시 라이브러리 함수 디스어셈 가능



6. 기타 옵션

-m32

 i386의 32비트 아키텍처로 컴파일

 -M, -MM

소스 파일 종속성 정보 표시 (makefile에 사용)

  -z execstack

 스택에 실행권한을 설정 ( DEP 해제 )


예시)

gcc -g -W Wall -O2 -o output file1.c file2.c

file1.c, file2.c 를 컴파일하고 링크하여 출력

실행파일 output 생성

소스 파일 중에 반드시 하나의 main() 함수가 있어야 한다.

'Note' 카테고리의 다른 글

GDB 사용법  (0) 2018.06.29
make 사용법 (+Makefile)  (0) 2018.06.29
git 명령어 & Bitbucket 사용하기  (0) 2018.06.27
Domain Name System - DNS와 네임서버  (0) 2017.06.20
운영체제별 개행문자(줄바꿈문자)  (0) 2017.06.20


원본 출처


장고(Django)는 웹 애플리케이션을 만들기 위한 파이썬 기반의 프레임워크로, 튼튼하며, 오픈 소스이다. 장고의 인기는 지난 2년 동안 증가해왔고, 이미 성숙한 단계에 있으며, 실제로 큰 규모의 단체들에게 이용되어진다.

웹 애플리케이션을 제작하기 위한 다른 파이썬 기반의 프레임워크들(Flask, Pyramid) 중에서도 장고는 가장 인기가 많다. 장고는 파이썬 버전 2.7과 3.6을 모두 지원한다. 이 글을 쓰는 시점에서 파이썬 2.7은 커뮤니티, third party packages, 그리고 온라인 문서화의 측면에서 여전히 이용가능한 버전이다. 장고는 적절하게 사용되면 안전하고, 높은 차원의 유연성을 제공한다. 바로 다음 내용이 파이썬을 사용한 서버 사이드 애플리케이션을 개발할 때 더 나아갈 수 있는 방법이다.

한 사람의 숙력된 파이썬 그리고 장고 개발자로써, 장고 설정(setup)에 대해 내가 몇 년동안 배우고 모아왔던 몇 가지 최고의 실행 방법을 여러분들과 공유할 것이다. 당신이 몇 개의 장고 프로젝트를 수행했는지, 혹은 이제 막 하나를 시작하는 단계인지와는 상관없이 여기에 기술된 방법들은 당신이 미래에 더 나은 애플리케이션을 만들도록 도와줄 것이다.

나는 당신들이 몇몇 툴들을 당신만의 개발 도구상자에 즉시 추가할 수 있도록 매우 실용적인 마음으로 이 글을 썼다. 당신은 심지어 다음 프로젝트를 위해 직접 제작한, 더욱 발전된 형태의 장고 표준 문서를 만들 수도 있다.

이 글의 목적을 위해, 당신이 리눅스 우분투(Linux Ubuntu)를 사용하고 있다고 가정한다.
글에서, $ 기호로 시작하는 1줄짜리 코드들은 해당 줄이 터미널에서 입력되어 져야 한다는 것을 강조하기 위한 것이다. 복붙할 때 $ 기호는 제외하라.


(자, 레쓰게릿)



Virtual Environment

파이썬 기반의 애플리케이션을 개발하는 과정에서, 지속적으로 third party package를 이용해왔다. 이러한 패키지들은 자주 업데이트되어지므로, 패키지들을 지속적으로 준비하는 것이 필수이다. 하나의 로컬 컴퓨터에서 다수의 프로젝트를 개발할 때, 각 패키지의 현 버전의 트랙(track)을 유지하는 것이 문제이다. 그 이유는 다른 프로젝트에서 같은 패키지의 다른 버전을 사용하는 것이 불가능하기 때문이다. (프로젝트 A에서 패키지 P의 1.2 버전을 사용하는데, 프로젝트 B에서 패키지 P의 1.4버전을 사용할 수 없다.) 게다가, 한 프로젝트에서 패키지를 업데이트하는 것이 다른 프로젝트에서 하나 또는 여러 개의 기능(functionality)의 역할을 하는 패키지들을 멈추게 할 수도 있다.

이런 문제는 가상 환경을 통해 해결될 수 있다. 직접 가상 환경(Virtual Environment)을 설정해보자.

우선 가상환경을 설치하라.

$ apt-get update
$ apt-get install python-pip python-dev build-essential

$ export LC_ALL="en_US.UTF-8" # 다음 줄에서 에러가 뜰 경우 쉘 환경 변수를 등록하라.

$ pip install --upgrade pip
$ pip install --upgrade virtualenv
$ mkdir ~/.virtualenvs
$ pip install virtualenvwrapper
$ export WORKON_HOME=~/.virtualenvs
$ nano ~/.bashrc



~/.bashrc 의 파일 끝에 아래 줄을 추가하라.

. /usr/local/bin/virtualenvwrapper.sh

(반드시 해당 경로에 해당 파일이 있는지 확인한 후 추가하세요.)
(만약 파일이 없다면, find / -name "virtualenvwrapper.sh" 명령어로 경로를 찾길 바랍니다.)


실행하라.

$ . .bashrc


설치가 끝나면, 프로젝트이름을 타이핑해서 새 가상 환경을 만들어라.

$ mkvirtualenv project_name


가상 환경에 있는 동안은 터미널에서 아래처럼 접두사가 추가된다는 것을 볼 것이다.

(project_name) ofir@playground:~$


가상 환경을 나가기 위해선 아래의 명령어를 사용하라. 이 명령어로 인해 로컬 컴퓨터의 실제 파이썬 컨텍스트로 되돌아 간다.

$ deactivate


특정 가상 환경 컨텍스트를 시작하려면 아래의 명령어를 사용하라.

$ workon project_name


본인의 로컬 머신에 존재하는 가상 환경들의 목록을 보려면 아래의 명령어를 사용하라.

$ lsvirtualenv


로컬 컴퓨터의 가상환경에서 프로젝트 의존성을 갖는 것은 분리된 환경에서 패키지들을 유지하도록 한다. 즉, 하나 또는 다수의 프로젝트만을 위해 특정 패키지들을 사용한다. 새 가상환경을 만들 때, 당신은 설치된 패키지 없이 완전히 새로운 가상환경에서 시작할 것이다. 그 때는 다른 가상환경에 있는 프로젝트와 동일한 패키지를 설치하더라도 다른 버전을 사용할 수 있다.

장고 설치를 예로 들면,

(project_name) $ pip install Django==1.11

(현재 장고 최신 버전은 2.0.5)

위에서 설치한 장고 1.11 버전은 오직 그 환경(여기선 project_name)에서만 이용가능한 것이다. 당신의 주요 파이썬 인터프리터 또는 로컬 컴퓨터의 다른 가상 환경 모두 당신이 그 환경에서 설치했던 새로운 장고 패키지에는 접근할 수 없을 것이다.

가상 환경을 이용하여 서버를 실행하는 명령을 사용하기 위해, 가상환경의 컨텍스트에서 아래와 같은 명령어를 사용하라.

(project_name) $ cd /path/to/django/project
(project_name) $ ./manage.py runserver


마찬가지로, 가상환경에서 파이썬 인터프리터에 들어가려면,

(project_name) $ python

이미 그 환경에서 설치된 패키지들을 이용할 수 있다.




Requirements

Requirements는 프로젝트에서 사용중인 파이썬 패키지의 목록으로, 각 패키지마다 이름버전이 함께 기록되어 있다.

아래는 requirements.txt 파일의 예시이다.

dicttoxml==1.7.4
Django==1.11.2
h5py==2.7.0
matplotlib==2.0.2
numpy==1.13.0
Pillow==4.1.1
psycopg2==2.7.1
pyparsing==2.2.0
python-dateutil==2.6.0
pytz==2017.2
six==1.10.0
xmltodict==0.11.0


requirements.txt 파일을 최신으로 유지하는 것은 다른 개발자들과 적절히 협업하는 데 있어 필수적이다. 또한 당신의 배포 환경을 적절하게 설정하는 것도 중요하다. 이 파일이 Code Repository 에 포함되어 있으면, 단 한 줄만 터미널에 입력하면 가상 환경에서 설치된 모든 패키지들을 업데이트할 수 있다. 그 때는 매우 짧은 시간에 실행하므로, 함께 일할 개발자를 깨울 수 있다.

requirements.txt 파일을 생성하거나 기존의 것을 갱신하기 위해, 가상환경 내에서 아래와 같은 명령어를 사용하라.

(project_name) $ pip freeze > requirements.txt


당신의 편리함을 위해, 이 명령어가 Git 저장소에 의해 트랙되어진 폴더에서 실행하는지 확인하라. 이는 다른 코드의 인스턴스가 requirements.txt 파일에 접근하는 것을 가능하게 한다.

만약 새 개발자가 팀에 합류하면, 또는 당신이 requirements.txt 파일에 기록된 동일한 패키지를 사용하는 새 환경을 설정하길 원한다면, 가상 환경 컨텍스트에서 아래의 명령어를 실행하라.

(project_name) $ cd /path/to/requirements/file
(project_name) $ pip install -r requirements.txt


파일에 기록된 모든 요구사항은 즉시 당신의 가상환경에 설치될 것이다. 오래된 버전들은 갱신될 것이고, 새로운 버전들은 파일의 요구사항에 정확히 맞추고자 다운그레이드(downgrade)될 것이다. 당신이 여전히 유지하길 원하는 환경들 사이에서 차이가 있을지도 모른다는 것에 주의하라!

나는 당신의 Work flow에 이 명령어들을 통합하는 것을 적극 추천한다. 저장소에 코드를 push 하기 전에 requirements.txt 파일을 갱신하라. 그리고 저장소로부터 코드를 pull한 후에 requirements.txt 파일을 설치하라.




Better settings.py configuration

장고는 매우 기본적이고 유용한 settings.py 파일을 즉시 사용할 수 있다. (즉, 기본적으로 제공한다는 소리) 이 파일은 당신의 프로젝트에서 메인이 되고, 매우 유용한 설정들을 정의한다. 또한 매우 간단하다. 다만 가끔, 개발자가 팀에서 일할 때, 배포 환경을 설정할 때, 혹은 당신이 기본으로 제공되는 settings.py 파일을 둘 이상 필요로 할 때 등 다양한 설정 파일이 요구될 수 있다.

다수의 설정 파일들은 개별적으로 각 환경을 위해 쉽게 사용자가 맞춤형으로 설정할 수 있게 한다. (여기서 환경은 위에서 언급한 가상 환경이 아닌, 실행 환경을 의미)

ALLOWED_HOSTS # for production environment
DEBUG
DATABASES # for different developers on the same team


settings.py 파일을 설정하기 위한 확장된 접근법을 제안하겠다. 이 방식은 당신이 다른 버전들을 유지하도록 해주고, 어떤 특정 시간과 특정 환경에서 원하는 패키지를 사용하도록 해준다.

첫번째, settings.py 파일 경로로 들어가라.

(project_name) $ cd /path/to/settings/file

(장고 프로젝트 폴더에 들어가면 project_name/settings.py 경로)

그 다음, settings 라는 이름의  새 모듈(=디렉토리)를 생성하라. 모듈은 __init__.py 파일을 포함하는 폴더이다.

(project_name) $ mkdir settings


settings.py 파일을 base.py 로 이름을 바꾸고 위에서 생성한 새 모듈(settings 폴더)로 그 파일을 옮겨라.

(project_name) $ mv settings.py settings/base.py


이 예시에서는, 당신이 개발환경과 배포환경만을 위한 하나의 settings 파일을 설정하길 원한다고 가정을 한다. 같은 팀 내 다른 개발자들은 다른 settings 파일을 정의하기 위해 정확히 동일한 방법을 사용할 수 있다.

개발 환경을 생성하라.

(project_name) $ nano settings/development.py


해당 파일 내에 아래와 같이 입력하라.

from .base import *

DEBUG = True


배포 환경을 생성하라.

(project_name) $ nano settings/production.py


해당 파일 내에 아래와 같이 입력하라.

from .base import *

DEBUG = False
ALLOWED_HOSTS = [‘app.project_name.com’, ]


이제는 당신이 구체적인 환경의 설정을 갱신하거나 추가하길 원할 때마다, 자신만의 settings 파일에서 쉽게 구현할 수 있다.

여러분들은 "장고는 각 환경에서 어떤 settings 파일을 로드할 지 어떻게 아는가"에 대해 궁금할 지도 모른다. 그것은 바로 __init__.py 파일이 이용되는 이유이다. 예를 들어, 서버를 실행할 때 로드하기 위해 장고가 settings.py를 찾을 때, 장고는 정확히 settings.py 파일 보다는 settings 모듈을 찾는다. 하지만 그 모듈이 __init__.py 파일을 포함해야만 장고가 그 모듈이 settings.py 파일과 같은 것이란 걸 알게 된다. 장고가 __init__.py 파일안에 무엇이 쓰여졌든지 그 파일을 로드해서 실행할 것이다.

그러므로, 우리는 어떤 settings 파일을 __init__.py 파일 안에 로드할 지를 정의할 필요가 있다.

(project_name) $ nano settings/__init__.py


파일 안에 아래와 같이 타이핑 하라. (배포 환경으로 설정할 경우)

from .production import *


이 방식에서, 장고는 매 실행마다 base.py와 production.py 를 모두 로드할 것이다.

이제 남은 유일한 설정은 당신의 .gitignore 파일에 __init__.py를 기록하는 것이다. 그래서 push와 pull을 할 때 포함되지 않게 한다. 일단 새 환경을 설정하면, settings 모듈에 새 __init__.py 파일을 생성하는 것을 잊지말라. 그 다음 전에 수행했던 것처럼 정확하게 요구되는 settings 파일을 임포트(import)하라.



끝으로,

이 글에서는 우리는 장고 프로젝트를 더 효율적으로 설정하기 위한 세 가지 (베스트) 실행 방식을 다루어보았다.

  1. 가상환경에서 작업하는 것

  2. 워크플로우에서 지속적으로 requirements.txt를 이용하고, 파일을 최신의 것으로 유지하는 것

  3. settings 모듈을 사용하여 설정하는 것



'Programming Language > Python' 카테고리의 다른 글

[정리 03] 유용한 기능들  (0) 2021.02.05
[정리 02] 표준 데이터 타입(Standard Data-Type)  (0) 2021.02.04
[정리 01] Python 기초  (0) 2021.02.04
간단한 알고리즘  (0) 2019.06.30
Tip (Reference)  (0) 2019.05.15


Git 명령어



1. 상태확인


git log
- HEAD : 현재 사용중인 브랜치, HEAD를 이동시켜 commit 선택 가능


어떻게 이동시키는가?

HEAD~N : N세대 앞의 커밋            ex) git log HEAD~1
HEAD^N : N번째 원본인지 지정    ex) git log HEAD^1


git log -p -n
 : 최신순으로 n개의 커밋보기



git log --stat

 : 수정 전 또는 삭제된 코드 보기



git status

 : untracked file 확인 가능. 즉, stage에 올라가지 않은 file 확인 가능 (add 명령 전)



2. branch

로컬 저장소용 브랜치 : master
원격 저장소용 브랜치 : origin
리모트 브랜치 : origin/master 또는 [원격저장소용 브랜치/로컬저장소용 브랜치]

* 각 commit은 현재 branch 에서 추가된다.

git branch [브랜치명]

  : 브랜치 생성



git branch --merged

 : 합친 브랜치 보기 (*는 현재 브랜치)


* 현재 A브랜치에 있을 때, B브랜치를 생성하면 나중에 B브랜치를 A브랜치에 합병할 수 있다.

이 때, B브랜치에 HEAD가 있을 것이다.


<브랜치 합병하기>

git checkout branchA

git merge branchB


이미 분기전 브랜치면 checkout은 할필요 x
부모 브랜치 상태에서 자식 브랜치들을 합병 (모든 커밋이 적용됨)



git branch --no-merged

 : 안합친 브랜치 보기

 

 
git checkout [브랜치명]

 : 브랜치 바꾸기

 
 
3. 원격저장소에 파일 올리기


<아래의 순서 유지>


git pull

 : 반드시 원격 저장소 내용을 로컬 저장소에 동기화 시킬 것. (동기화 안되어 있을 경우 push 할 때 거절됨)



git add [FilePath]
 : stage에 올리기. 다올리려면 --all 옵션 추가



git commit -m "message"
 : 변경사항을 인덱스(INDEX)에 올리기. stage에 올라온 내용만 커밋가능.



git push -u origin [현재브랜치명]
  : master가 일반적이나, 새 브랜치일 경우 origin/새브랜치명 으로 리모트 브랜치가 생성된다. 이미 있다면 해당 리모트 브랜치에 내용물이 올라간다.



4. 취소하기


git reset

 : 이전의 커밋으로 HEAD가 이동.

--mixed : (default)  인덱스는 변경사항이 저장된 곳(?)인데, 이 옵션을 추가하면 커밋만 취소되고, 실제 인덱스에는 커밋내용이 담겨져 있음. 즉, 취소한 걸 또 취소할 수 있다. 이전의 커밋으로 HEAD가 이동한다.

--hard : 작업 디렉토리(로컬 저장소)와 인덱스 동기화. 이전 커밋내용이 날아간다~~



5. 리모트 브랜치를 로컬저장소에 동기화시키기


git checkout [로컬 저장소의 브랜치]


git reset --hard [원하는 리모트 브랜치]
 : 궂이 [origin/로컬브랜치]가 아니어도 된다. 즉, 현재 master 브랜치에 있더라도 origin/abc 나 origin/def 와 같은 리모트 브랜치의 것도 동기화가 된다.

git push origin [현재 로컬 브랜치]
 : 위에서 싹 청소시킨 [원하는 리모트 브랜치]를 "origin/로컬브랜치"의 내용물로 덮어쓴다.
    명령 후 상태는 origin/로컬브랜치 = 원하는 리모트 브랜치

ex)

git checkout master

git reset --hard origin/test

git push origin master

-> origin/master = origin/test



6. 그냥 리모트 브랜치를 로컬에 가져오기(로컬에서 보기)


git checkout --track [원하는 리모트 브랜치]





Bitbucket 사용하기 (+ AWS)

1. SSH 키 생성하기


ssh-keygen

 : 로컬컴퓨터(경로는 ~/.ssh/)에서 키 생성 (passphrase-암호문은 생성안해도 괜찮음)

* .pub 확장자가 퍼블릭 키이다.



2. 생성한 Public Key는 Bitbucket 설정에서 사이트에 올릴 것


Repository Setting이 아닌 Project Setting에서 ssh public key를 등록



3. 혹시모르니 내 컴퓨터에서 키 등록


ssh-add ~/.ssh/<private_key_file>


4. 등록된 ssh 리스트 보기


ssh-add -l



5. AWS 인스턴스에서 ~/.ssh/ 에다가 1번에서 생성한 Private Key를 저장 (Not Public)


내용물을 복사해도 완전히 붙여넣기가 안될 수 있으므로 확인해야함 (이거땜에 삽질 ㅡㅡ)



6. aws 인스턴스에서 Bitbucket으로 로그인해보기


ssh  -Tv  username@bitbucket.org


(옵션은 디버깅옵션)

logged in 뜨면 성공
안뜨면 ping 찍어서 Security Group에 인바운드/아웃바운드 정책 맞게 설정했는지 볼 필요 OOOOOO


+기타 명령어)
ps -e | grep ssh-agent

 : ssh가 실행중인지 확인할 것 (실행되면 ok)



7. Bitbucket 저장소에서 내용물을 받아보자.(또는 올려보자)


git init

git clone ~~~
git remote set-url origin [HTTPS URL]

git pull --all 또는 git add --all

git commit -m ""
git push -u origin master



'Note' 카테고리의 다른 글

make 사용법 (+Makefile)  (0) 2018.06.29
GCC 사용법  (0) 2018.06.29
Domain Name System - DNS와 네임서버  (0) 2017.06.20
운영체제별 개행문자(줄바꿈문자)  (0) 2017.06.20
FPS : Frames Per Second  (1) 2017.03.28

+ Recent posts