pantsbuild #general

Channels

welcome

github-notifications

announce

witty-crayon-22786

09/01/2015, 7:45 PM

gotcha, cool.

witty-crayon-22786

09/01/2015, 7:46 PM

yea, makes sense.

enough-analyst-54434

09/01/2015, 7:46 PM

and no-ops is 0 inbound deps from a target language

witty-crayon-22786

09/01/2015, 7:46 PM

yep

enough-analyst-54434

09/01/2015, 7:46 PM

you don't have either problem here

enough-analyst-54434

09/01/2015, 7:46 PM

You're saved by a canonical target language

enough-analyst-54434

09/01/2015, 7:46 PM

and the activation just flips from that default to js ... in a seperate task

enough-analyst-54434

09/01/2015, 7:47 PM

The objection to Codegen for thrift was there was no default

enough-analyst-54434

09/01/2015, 7:47 PM

... and caching/impl bugs - but those are lesser things in the realm of conceptual objections

jolly-chef-92794

09/01/2015, 7:52 PM

So, it doesn’t look the the BUILD dictionary docs can pick up nested objects; so would it be preferred to do something like

jolly-chef-92794

09/01/2015, 7:53 PM

Copy code

jvm_binary(name=‘foo’,
  shading_rules=[
    ShadingExclude('...'),
    ShadingRelocate('...'),
  ],
)

rather than

Copy code

jvm_binary(name=‘foo’,
  shading_rules=[
    Shading.Exclude('...'),
    Shading.Relocate('...'),
  ],
)

enough-analyst-54434

09/01/2015, 7:58 PM

Are you trying

objects={'shading_exclude': Shading.Exclude}

in register.py?

enough-analyst-54434

09/01/2015, 7:58 PM

All the docgen looks at is aliases iiuc

jolly-chef-92794

09/01/2015, 8:02 PM

Yeah I’m basically doing that; I just thought it might be nice to have the shading rule constructors accessible in BUILD files as

Shading.Foo

rather than

shading_foo

, because it mimics the look of `Duplicate`/`Skip` from

jar_rules

, but I don’t want to pollute the build file aliases with more very generic looking object names (especially since

exclude

already exists)

enough-analyst-54434

09/01/2015, 8:02 PM

I don;t think we disallow .

enough-analyst-54434

09/01/2015, 8:02 PM

in the alias

enough-analyst-54434

09/01/2015, 8:03 PM

but I agree with your larger point

enough-analyst-54434

09/01/2015, 8:03 PM

it would be nice for wymbols to be lexically scoped

enough-analyst-54434

09/01/2015, 8:03 PM

so you could just say 'exclude' inside the scope of jvm_binary

enough-analyst-54434

09/01/2015, 8:03 PM

and not have it conflict with a jar exclude say

jolly-chef-92794

09/01/2015, 8:04 PM

Yeah that’d be very nice. For this purpose it’d have to be even more fine-grained though, since

exclude()

and

Shading.Exclude

would both be used in

jvm_binary

, just in different args

enough-analyst-54434

09/01/2015, 8:04 PM

oh, right the . would not work in the alias

enough-analyst-54434

09/01/2015, 8:04 PM

well, if we get lexical scoping, presumably it would be actual lexical scoping and that would still work

jolly-chef-92794

09/01/2015, 8:05 PM

As things are, I can just alias a

Shading

object which has references to the

Exclude

type, but we don’t generate docs for them in

build_dictionary.html

doing it that way

jolly-chef-92794

09/01/2015, 8:06 PM

The lexical scoping I imagine would require formally parsing the BUILD files with a real parser, instead of just making python execute them?

enough-analyst-54434

09/01/2015, 8:06 PM

Thats back to my 1st point thoug - my objects example should both allow nasty namespacing and proper builddict

enough-analyst-54434

09/01/2015, 8:06 PM

does that not actually work in practice?

enough-analyst-54434

09/01/2015, 8:07 PM

ie alias the nested type directly

enough-analyst-54434

09/01/2015, 8:07 PM

don;t have the BUILD writer traverse the dot

jolly-chef-92794

09/01/2015, 8:07 PM

objects={’shading_relocate': Shading.Relocate,}

works fine, if that’s what you’re meaning.