Error on multiple files with same basenames in target. (issue 10010028)

[tha...@chromium.org]

Reviewers: Mark Mentovai,

Message:
The motivation is to make gyp more uniform across build systems. Static
libraries where several files have the same basename are build time errors
in
msvc, and libtool warns about them.

Description:
Error on multiple files with same basenames in static library targets.

Please review this at http://codereview.chromium.org/10010028/

SVN Base: http://gyp.googlecode.com/svn/trunk/

Affected files:
M pylib/gyp/input.py
A test/same-name/gyptest-fail.py
M test/same-name/src/all.gyp
A test/same-name/src/double.gyp

[sco...@chromium.org]

On 2012/04/05 22:43:45, Nico wrote:
> The motivation is to make gyp more uniform across build systems. Static
> libraries where several files have the same basename are build time
> errors in
> msvc, and libtool warns about them.

I think this is a sort-of bug in msvs.py. (Pretty sure IDE-created projects
will
rename the duplicate .obj files to avoid the problem).

I agree with disallowing it for consistency though, probably just disallow
it in
all target types rather than only static_library?

https://chromiumcodereview.appspot.com/10010028/diff/5/pylib/gyp/input.py
File pylib/gyp/input.py (right):

https://chromiumcodereview.appspot.com/10010028/diff/5/pylib/gyp/input.py#newcode2116
pylib/gyp/input.py:2116: is_compiled_file = ext in ['.c', '.cc', '.m',
'.mm', '.s', '.S']
+= .cpp? (or is there a canonical list like this somewhere?)

https://chromiumcodereview.appspot.com/10010028/

[tha...@chromium.org]

On 2012/04/05 23:12:49, scottmg wrote:
> On 2012/04/05 22:43:45, Nico wrote:
> > The motivation is to make gyp more uniform across build systems. Static
> > libraries where several files have the same basename are build time
> errors
in
> > msvc, and libtool warns about them.

> I think this is a sort-of bug in msvs.py. (Pretty sure IDE-created
> projects
will
> rename the duplicate .obj files to avoid the problem).

Do you know in which way? If this is fixable in msvs.py, that's better.

> I agree with disallowing it for consistency though, probably just
> disallow it
in
> all target types rather than only static_library?

ffmpeg (a loadable_module) has some violations:

pcm: libavcodec/pcm.c libavformat/pcm.c
audioconvert: libavcodec/audioconvert.c libavutil/audioconvert.c
options: libavcodec/options.c libavformat/options.c
utils: libavcodec/utils.c libavformat/utils.c libavutil/utils.c
cpu: libavutil/x86/cpu.c libavutil/cpu.c

> https://chromiumcodereview.appspot.com/10010028/diff/5/pylib/gyp/input.py
> File pylib/gyp/input.py (right):

https://chromiumcodereview.appspot.com/10010028/diff/5/pylib/gyp/input.py#newcode2116
> pylib/gyp/input.py:2116: is_compiled_file = ext in
> ['.c', '.cc', '.m', '.mm',
> '.s', '.S']
> += .cpp? (or is there a canonical list like this somewhere?)

Done, cxx as well. make.py and ninja.py have extension lists. I haven't
anything
in non-generator code.

https://chromiumcodereview.appspot.com/10010028/

[Scott Graham]

On Thu, Apr 5, 2012 at 4:23 PM, <tha...@chromium.org> wrote:

On 2012/04/05 23:12:49, scottmg wrote:

On 2012/04/05 22:43:45, Nico wrote:
> The motivation is to make gyp more uniform across build systems. Static
> libraries where several files have the same basename are build time errors

in

> msvc, and libtool warns about them.

I think this is a sort-of bug in msvs.py. (Pretty sure IDE-created projects

will

rename the duplicate .obj files to avoid the problem).

Do you know in which way? If this is fixable in msvs.py, that's better.

The ide uses /Fdblah2.obj, but I'm not sure w/o trying it how complicated that would be to plumb through msvs.py for 2008/10 (because replacing .cc with .obj won't be right anymore)

 

I agree with disallowing it for consistency though, probably just disallow it

in

all target types rather than only static_library?

ffmpeg (a loadable_module) has some violations:

pcm: libavcodec/pcm.c libavformat/pcm.c
audioconvert: libavcodec/audioconvert.c libavutil/audioconvert.c
options: libavcodec/options.c libavformat/options.c
utils: libavcodec/utils.c libavformat/utils.c libavutil/utils.c
cpu: libavutil/x86/cpu.c libavutil/cpu.c

Dastardly.

[Mark Mentovai]

Let's be careful here. If this is indeed a limitation of MSVS, then the "least common denominator" philosophy dictates that we proceed with your proposal. On the other hand, if MSVS and all other environments tolerate this case, warnings notwithstanding, it would be prudent to treat this as an msvs.py bug, fix it, and add a test for it.

I can envision cases where a project might legitimately have like-named files going into the same static library. One would be atomic_ops.cc and atomic_ops.S. Another would be bindings/c/interface.cc and bindings/cplusplus/interface.cc.

[Scott Graham]

On Thu, Apr 5, 2012 at 4:25 PM, Scott Graham <sco...@chromium.org> wrote:

On Thu, Apr 5, 2012 at 4:23 PM, <tha...@chromium.org> wrote:

On 2012/04/05 23:12:49, scottmg wrote:

On 2012/04/05 22:43:45, Nico wrote:
> The motivation is to make gyp more uniform across build systems. Static
> libraries where several files have the same basename are build time errors

in

> msvc, and libtool warns about them.

I think this is a sort-of bug in msvs.py. (Pretty sure IDE-created projects

will

rename the duplicate .obj files to avoid the problem).

Do you know in which way? If this is fixable in msvs.py, that's better.

The ide uses /Fdblah2.obj

er, /Fo.

[ma...@chromium.org]

LGTM

http://codereview.chromium.org/10010028/