Sent from my iPad
On Feb 21, 2017, at 5:18 AM, Dimitri Racordon <[email protected]> wrote: >> Maybe we should try to collect what people want from submodules first. > > I’d like a simple method to group my sources files into some kind lexical > scope. Nothing more actually =D I think we have very similar desires for a submodule system. I'm goi to write up some thoughts as soon as I have a chance, but today is very busy so it may not be until tomorrow. > >> The point is, specifying which files belong to which submodules is a build >> system responsibility, not a language responsibility. This keeps source code >> portable, avoids boilerplate, and keeps submodule information from being >> duplicated (and thus potentially becoming inconsistent) in file system >> structure or build system metadata. > > Although I think this assertion makes a lot of sense, wouldn’t it be better > for the language to be a bit more opinionated about that? The problem I > foresee is when people will start making frameworks with Xcode while others > will opt for SwiftPM. I guess compatibility between the two default > architectures could easily become hellish. For instance, building/linking > C/C++ libraries is a hell as soon as you have more than a single dependency. > Everybody has another system to do build their library (make, cmake, > autotools, Xcode, …), and people end up rewriting unified build configuration > scripts for whatever tool they use. > > Ideally, I’d prefer an opinionated submodule system that clearly distinguish > what is part of a submodule from what is not, would it be filesystem-based > (my personal favoured) or meta-data based by the means of a manifest or some > other directives within the source files (my personal least favoured). > > I like filesystem-based approaches as they are simple to teach and simple to > put in place, with and IDE **as well as** with a simple shell. I personally > find Python’s approach to be very successful in that regard. The only > improvement I would like for Swift is not having to write a dozen of `import > foo.bar.baz.koala` at the beginning of my sources. Maybe that could be > achieved if importing one module would also make all the public entities of > its submodules visible. > >> I wonder if we should have something like “module manifest” for all of a >> library’s public submodules, similar to SwiftPM's package manifest. So, >> strawman syntax… > > > Writing manifest files is tedious and error-prone when done by hand, I’ll > also add that the usability of language shouldn’t depend on some IDE (yes I’m > looking at you Java). Writing one and one only manifest for the top-level > module is fine and makes sense (specifying targets, dependencies, ...). But > I’d argue that writing one for every submodule would be annoying to create > and maintain. Also, I’m not convinced that everything need that much > information. The multiple versions of a submodule are probably already stored > in some versioning tool and the description will most often be a wordy > version of the module’s name. > >> Have the people who want modules tried SPM yet? > > Yes I did and to be honest it is close to a perfect solution for me. It’s > mostly filesystem-based, easy to teach and easy put in place. In my dreams, > submodules would just be an easier way to bundle a bunch of sources together, > than having to manually link modules via a dependency list in their > respective in manifest files. > > Best regards, > Dimitri > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
