Allow files with the same basename to exist within the same project.

Allow files with the same basename to exist within the same project.

A related change adds a command line option to enable duplicate basenames:
https://codereview.chromium.org/12063003/

[Sam Clegg, 2013-02-28 17:35:26]

Seems like a much nicer solution to me.

LG to me, but might want to get approval from thakis who added that TODO.

https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py
File pylib/gyp/input.py (right):

https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py#newcode2333
pylib/gyp/input.py:2333: if variables.get('GENERATOR', '') != 'msvs' or \
nit: No need to pass second arg to get()

https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py#newcode2334
pylib/gyp/input.py:2334: int(variables.get('MSVS_VERSION', '9999')) > '2008':
Is it possible that MSVS_VERSION is not set when generator is msvs?   It not
then maybe drop the second arg to get here too?

[Sam Clegg, 2013-02-28 17:37:00]

Is there a test for duplicate basenames?  If so, could it be extended
to test this 2008 distinction?  If not, could you add one?

On 2013/02/28 17:35:26, Sam Clegg wrote:
> Seems like a much nicer solution to me.
> 
> LG to me, but might want to get approval from thakis who added that TODO.
> 
> https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py
> File pylib/gyp/input.py (right):
> 
> https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py#newcode2333
> pylib/gyp/input.py:2333: if variables.get('GENERATOR', '') != 'msvs' or \
> nit: No need to pass second arg to get()
> 
> https://codereview.chromium.org/12381003/diff/1/pylib/gyp/input.py#newcode2334
> pylib/gyp/input.py:2334: int(variables.get('MSVS_VERSION', '9999')) > '2008':
> Is it possible that MSVS_VERSION is not set when generator is msvs?   It not
> then maybe drop the second arg to get here too?

[Nico, 2013-02-28 17:41:01]

I like this.

Do duplicate basenames work correctly with xcodebuild (I think so?) and the
android.mk build system (no idea)?

[Sam Clegg, 2013-02-28 17:46:32]

+torne who has android build knowledge.

We have android trybots now (right?) so presumably a well
crafted test should be all we need to determine support
(or lack of) for each generator.

[Torne, 2013-03-01 14:33:40]

On 2013/02/28 17:46:32, Sam Clegg wrote:
> +torne who has android build knowledge.

I think the generator and build system itself should be fine with it, but this
change (https://android-review.googlesource.com/#/c/50683/) in AOSP suggests
that Intel's toolchain isn't happy with it so it's possible that we may not want
to allow it with android even if it works for other tools. :/

> We have android trybots now (right?) so presumably a well
> crafted test should be all we need to determine support
> (or lack of) for each generator.

Yes, there is a working trybot and so you can just send a job to gyp-android to
test this (though bear in mind what I said above, I'm not sure we want to allow
it even if it works.

[bradn, 2013-03-06 18:47:13]

Sorry for the slow reply, been out sick.

https://codereview.chromium.org/12381003/diff/6001/pylib/gyp/input.py
File pylib/gyp/input.py (right):

https://codereview.chromium.org/12381003/diff/6001/pylib/gyp/input.py#newcode...
pylib/gyp/input.py:2332: # For all other build configs, duplicates are OK.
Theres a bunch of version plumbing, this would seem to ignore that. Look in
MSVSVesion.py

Also, I believe the idea around this was to discourage folks from producing gyp
files that won't work with all the generators. In what context are you hoping to
use this?

[Sam Clegg, 2013-05-24 16:49:07]

On 2013/03/06 18:47:13, bradn wrote:
> Sorry for the slow reply, been out sick.
> 
> https://codereview.chromium.org/12381003/diff/6001/pylib/gyp/input.py
> File pylib/gyp/input.py (right):
> 
>
https://codereview.chromium.org/12381003/diff/6001/pylib/gyp/input.py#newcode...
> pylib/gyp/input.py:2332: # For all other build configs, duplicates are OK.
> Theres a bunch of version plumbing, this would seem to ignore that. Look in
> MSVSVesion.py
> 
> Also, I believe the idea around this was to discourage folks from producing
gyp
> files that won't work with all the generators. In what context are you hoping
to
> use this?

I guess it makes sense to only support the lowest common denominator features. 
How long do we need to continue to support 2008 anyway?
Does chrome still use it?

[pwnall-personal, 2014-01-15 15:56:05]

On 2013/05/24 16:49:07, Sam Clegg wrote:
> I guess it makes sense to only support the lowest common denominator features.

> How long do we need to continue to support 2008 anyway?
> Does chrome still use it?

To the best of my knowledge, Chromium is on VS 2010 now, and in the process of
migrating to 2013.
https://code.google.com/p/chromium/issues/detail?id=309197
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/jblTeRKe7sk

The Windows build instructions only mention VS 2010, so 2008 seems out the
picture.
http://www.chromium.org/developers/how-tos/build-instructions-windows


Given this context, would this CL (or one derived from it) be acceptable?

I'd like to use gyp and ninja to build a project of my own, but I hit this issue
with a third-party dependency. If possible, I'd rather change gyp than have to
patch the third-party code. I'm willing to pick up the work in this CL if the
original author isn't interested in it anymore.

[Sam Clegg, 2014-11-14 17:21:58]

On 2014/01/15 15:56:05, pwnall wrote:
> On 2013/05/24 16:49:07, Sam Clegg wrote:
> > I guess it makes sense to only support the lowest common denominator
features.
> 
> > How long do we need to continue to support 2008 anyway?
> > Does chrome still use it?
> 
> To the best of my knowledge, Chromium is on VS 2010 now, and in the process of
> migrating to 2013.
> https://code.google.com/p/chromium/issues/detail?id=309197
>
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/jblTeRKe7sk
> 
> The Windows build instructions only mention VS 2010, so 2008 seems out the
> picture.
> http://www.chromium.org/developers/how-tos/build-instructions-windows
> 
> 
> Given this context, would this CL (or one derived from it) be acceptable?
> 
> I'd like to use gyp and ninja to build a project of my own, but I hit this
issue
> with a third-party dependency. If possible, I'd rather change gyp than have to
> patch the third-party code. I'm willing to pick up the work in this CL if the
> original author isn't interested in it anymore.

Its sounds the the best way forward for this change would be completely drop
support for <= 2008  (if that has not been done already in the mean time).
Can you take a look and/or close this issue?

[scottmg, 2014-11-14 17:23:27]

On 2014/11/14 17:21:58, Sam Clegg wrote:
> On 2014/01/15 15:56:05, pwnall wrote:
> > On 2013/05/24 16:49:07, Sam Clegg wrote:
> > > I guess it makes sense to only support the lowest common denominator
> features.
> > 
> > > How long do we need to continue to support 2008 anyway?
> > > Does chrome still use it?
> > 
> > To the best of my knowledge, Chromium is on VS 2010 now, and in the process
of
> > migrating to 2013.
> > https://code.google.com/p/chromium/issues/detail?id=309197
> >
>
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/jblTeRKe7sk
> > 
> > The Windows build instructions only mention VS 2010, so 2008 seems out the
> > picture.
> > http://www.chromium.org/developers/how-tos/build-instructions-windows
> > 
> > 
> > Given this context, would this CL (or one derived from it) be acceptable?
> > 
> > I'd like to use gyp and ninja to build a project of my own, but I hit this
> issue
> > with a third-party dependency. If possible, I'd rather change gyp than have
to
> > patch the third-party code. I'm willing to pick up the work in this CL if
the
> > original author isn't interested in it anymore.
> 
> Its sounds the the best way forward for this change would be completely drop
> support for <= 2008  (if that has not been done already in the mean time).
> Can you take a look and/or close this issue?

https://code.google.com/p/gyp/source/detail?r=1993