Thanks for this discussion Fil! We can leave it the way it is as long as we document it (in the README.rd / Adding a New Platform). I wasted too much time yesterday trying to figure out why my plugins weren't loaded and executed :-)
On Tue, Apr 17, 2012 at 7:29 PM, Patrick Mueller <[email protected]> wrote: > On Tue, Apr 17, 2012 at 20:14, Filip Maj <[email protected]> wrote: > > > Ahh, so if I update all of the module string Ids and axe the extra > > <platform> directory - we are all good, ya? Was wondering if there was > > specific reasoning other than "this is how we did it before". > > > > I read "update all of the module string ids" as "change the module ids used > in require() invocations" and "axe the extra <platform> directory" as "mv > {platform}/plugin/{platform}/* {platform}/plugin" then things will still > work, assuming the module id's you change in require() match the new module > names. > > However ... > > There's something to be said for having the platform name in the module id. > I happen to like it. It's not required, of course, but I like it. It > would certainly be possible to change the build to reshape the story so > there weren't "duplicate" platform names in the file path, but still was a > platform name in the module id, for instance. > > I don't care enough about this, either way, though, to work on any > alternative approaches. > > The other thing to think about is - what happens when we have a 3rd party > plugin story. Presumably you would "package" your plugin modules in a > single wad, somehow separating out platform-specific files. It's seems > like a reasonable possibility that the module ids might contain the > platform name, and that might be a significant part of how the plugin is > structured. Or, of course, maybe it won't. We don't know. > > From that aspect, the effort to rejigger all this stuff seems like a waste > of time, to me. > > -- > Patrick Mueller > http://muellerware.org >
