Обсуждение: pgsql: Fix ecpg test building process to not generate *.dSYM junk on Ma

Поиск
Список
Период
Сортировка

pgsql: Fix ecpg test building process to not generate *.dSYM junk on Ma

От
Tom Lane
Дата:
Fix ecpg test building process to not generate *.dSYM junk on Macs.

The trick is to not try to build executables directly from .c files,
but to always build the intermediate .o files.  For obscure reasons,
Darwin's version of gcc will leave debug cruft behind in the first
case but not the second.  Per complaint from Robert Haas.

Branch
------
REL9_0_STABLE

Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=72ba1f2c67e058755e21165ad8efcb0849abacd5

Modified Files
--------------
src/interfaces/ecpg/test/Makefile.regress |    3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)


Re: pgsql: Fix ecpg test building process to not generate *.dSYM junk on Ma

От
Bruce Momjian
Дата:
Tom Lane wrote:
> Fix ecpg test building process to not generate *.dSYM junk on Macs.
>
> The trick is to not try to build executables directly from .c files,
> but to always build the intermediate .o files.  For obscure reasons,
> Darwin's version of gcc will leave debug cruft behind in the first
> case but not the second.  Per complaint from Robert Haas.

A Makefile comment would have been nice so this is not un-done in the
future.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Re: pgsql: Fix ecpg test building process to not generate *.dSYM junk on Ma

От
Tom Lane
Дата:
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Fix ecpg test building process to not generate *.dSYM junk on Macs.
>>
>> The trick is to not try to build executables directly from .c files,
>> but to always build the intermediate .o files.  For obscure reasons,
>> Darwin's version of gcc will leave debug cruft behind in the first
>> case but not the second.  Per complaint from Robert Haas.

> A Makefile comment would have been nice so this is not un-done in the
> future.

Putting a comment there wouldn't really help.  If this is ever broken
again, the odds are just about 100% that the breakage will be somewhere
else.  I tried to think of someplace in our documentation where makefile
writing conventions in general could be documented, but came up empty.

            regards, tom lane