구차니의 잡동사니 모음

가장 간편(?)한 건...

그런데 이렇게 건드리는게 옳은건가...

[링크 : https://forums.xilinx.com/.../Trouble-configuring-petalinux-2013-10-bin-sh-1-pushd-not-found/td-p/399843]

SHELL 변수로 설정되지 않으면 /bin/sh가 되므로

bash에서 지원하는 popd pushd 등이 봉인..

환경 변수 등을 끌어 가지 않으므로.. 결론은 Makefile 별로 설정을 해주어야 한다.

5.3.2 Choosing the Shell

The program used as the shell is taken from the variable SHELL. If this variable is not set in your makefile, the program /bin/sh is used as the shell. The argument(s) passed to the shell are taken from the variable .SHELLFLAGS. The default value of .SHELLFLAGS is -c normally, or -ec in POSIX-conforming mode.

Unlike most variables, the variable SHELL is never set from the environment. This is because the SHELL environment variable is used to specify your personal choice of shell program for interactive use. It would be very bad for personal choices like this to affect the functioning of makefiles. See Variables from the Environment.

Furthermore, when you do set SHELL in your makefile that value is not exported in the environment to recipe lines that make invokes. Instead, the value inherited from the user’s environment, if any, is exported. You can override this behavior by explicitly exporting SHELL (see Communicating Variables to a Sub-make), forcing it to be passed in the environment to recipe lines.

[링크 : https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html]

    [링크 : https://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html]

 In short, variables defined with := are expanded once, but variables defined with = are expanded whenever they are used.

[링크 : http://stackoverflow.com/.../whats-the-difference-between-and-in-makefile]

Simply expanded variables are defined by lines using ‘:=’ or ‘::=’ (see Setting Variables). Both forms are equivalent in GNU make; however only the ‘::=’ form is described by the POSIX standard (support for ‘::=’ was added to the POSIX standard in 2012, so older versions of make won’t accept this form either).

[링크 : http://www.gnu.org/software/make/manual/html_node/Flavors.html#Flavors]

https://www.gnu.org/software/make/manual/html_node/Setting.html#Setting

gcc -M을 통해서 해당 소스가 끌어와야 하는 헤더들의 목록을 얻어낼수 있다.

이걸 이용하여 역으로

make 파일에서 사용해야 하는 헤더들의 목록을 생성해 낼 수 있고

이걸 make dep나 make depend를 통해서 수행하게 된다.

생각해보니.. ifdef로 된거.. option 파일이 아닌

-D 인자를 통해서 gcc -M -Dflag 해주면... 외부에서 소스변경없이 구현이 가능해져서 더 편하려나?

[링크 : http://developinghappiness.com/?p=174]

    [링크 : http://developinghappiness.com/?page_id=222]

[링크 : http://linux.die.net/man/1/gccmakedep]

타겟을 만들지 않아도 컴파일 되는 이유... 라고 해야하나?

*.c는 $(CC)를

*.cc나 *.C는 $(CXX)를 이용해서 컴파일 하는데

$(CPPFLAGS) 와 $(CFLAGS)를 인자로 받으니..

여기에 헤더와 링커 경로를 넣어주면 자동으로 알아서 작동하는 마법!

[링크 : http://korea.gnu.org/manual/4check/make-3.77/ko/make_10.html#SEC91]

‘warning: jobserver unavailable: using -j1. Add `+' to parent make rule.’

In order for make processes to communicate, the parent will pass information to the child. Since this could result in problems if the child process isn’t actually a make, the parent will only do this if it thinks the child is a make. The parent uses the normal algorithms to determine this (see How the MAKE Variable Works). If the makefile is constructed such that the parent doesn’t know the child is a make process, then the child will receive only part of the information necessary. In this case, the child will generate this warning message and proceed with its build in a sequential manner.

make 프로세스가 통신을 하기 위해서, 부모는 자식에게 정보를 넘겨줄 것이다. 자식 프로세스가 실제로 make를 하지 못하는 문제가 발생하기 전까지, 부모는 자식이 make를 진행 중이라고 생각을 할 것이다. 부모는 이것을 결정하기 위한 일반적인 알고리즘을 사용한다(How the MAKE Variable Works를 볼 것). 만약 makefile이 부모가 자식이 make 프로세스란걸 알지 못 하는 것과 같은 구조로 짜여있을 경우, 자식은 필요한 정보의 일부분만 받게 될 것이다. 이경우, 자식은 이 경고 메시지를 생성하고 자신의 빌드를 순차적인 방법으로 진행할 것이다.

[링크 : https://www.gnu.org/software/make/manual/html_node/Error-Messages.html]

Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’, as shown here:

subsystem:

        cd subdir && $(MAKE)

[링크 : https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable]

한줄 요약하자면..

병렬 구조로 안짜여졌으니 병렬로 안하겠어! 라는 의미

해결책은..

make -c ... 

이런거 대신

$(MAKE) -c ...

이런식으로 MAKE 변수를 써라.. 인가?

+

Only certain flags go into $(MAKEFLAGS).  -j isn't included because the sub-makes communicate with each other to ensure the appropriate number of jobs are occuring

Also, you should use $(MAKE) instead of make, since $(MAKE) will always evaluate to the correct executable name (which might not be make).

[링크 : http://stackoverflow.com/questions/9147196/makefile-pass-jobs-param-to-sub-makefiles]

The ‘-j’ option is a special case (see Parallel Execution). If you set it to some numeric value ‘N’ and your operating system supports it (most any UNIX system will; others typically won’t), the parent make and all the sub-makes will communicate to ensure that there are only ‘N’ jobs running at the same time between them all. Note that any job that is marked recursive (see Instead of Executing Recipes) doesn’t count against the total jobs (otherwise we could get ‘N’ sub-makes running and have no slots left over for any real work!)

If your operating system doesn’t support the above communication, then ‘-j 1’ is always put into MAKEFLAGS instead of the value you specified. This is because if the ‘-j’ option were passed down to sub-makes, you would get many more jobs running in parallel than you asked for. If you give ‘-j’ with no numeric argument, meaning to run as many jobs as possible in parallel, this is passed down, since multiple infinities are no more than one.

If you do not want to pass the other flags down, you must change the value of MAKEFLAGS, like this:

subsystem:

        cd subdir && $(MAKE) MAKEFLAGS=

The command line variable definitions really appear in the variable MAKEOVERRIDES, and MAKEFLAGS contains a reference to this variable. If you do want to pass flags down normally, but don’t want to pass down the command line variable definitions, you can reset MAKEOVERRIDES to empty, like this:

MAKEOVERRIDES =

This is not usually useful to do. However, some systems have a small fixed limit on the size of the environment, and putting so much information into the value of MAKEFLAGS can exceed it. If you see the error message ‘Arg list too long’, this may be the problem. (For strict compliance with POSIX.2, changing MAKEOVERRIDES does not affect MAKEFLAGS if the special target ‘.POSIX’ appears in the makefile. You probably do not care about this.)

A similar variable MFLAGS exists also, for historical compatibility. It has the same value as MAKEFLAGS except that it does not contain the command line variable definitions, and it always begins with a hyphen unless it is empty (MAKEFLAGS begins with a hyphen only when it begins with an option that has no single-letter version, such as ‘--warn-undefined-variables’). MFLAGS was traditionally used explicitly in the recursive make command, like this:

subsystem:

        cd subdir && $(MAKE) $(MFLAGS)

but now MAKEFLAGS makes this usage redundant. If you want your makefiles to be compatible with old make programs, use this technique; it will work fine with more modern make versions too.

[링크 : https://www.gnu.org/.../html_node/Options_002fRecursion.html#Options_002fRecursion]