TODOs
Henrik Feldt edited this page Oct 27, 2013
·
18 revisions
- Ruby (gems, tests)
- Javascript (compiler/minimizer, tests)
- Mono/F# (xbuild/albacore@clean_slate, tests)
- ...?
- Rule documentation: https://github.com/chrisvana/repobuild/wiki/Rules
- Hah. Poor fools.
- conditionals (gcc, clang, mac, library>=version, has library, etc) -- What is there is ugly. This is tricky to do cleanly without making the build rules a mess.
- other build standards (e.g. Maven, Ant, Grape, similar to how we support cmake/automake/etc)... these could be plugins.
- java jar rules: merging jars, declaring jar libraries, etc.
- fileset rules (creates symlinked directory with a set of files in it)
- non-cc embed_data rules (e.g. java_embed_data py_embed_data ... similar to cc_embed_data)
- SWIG
- sh_test
- mono dll rules: declarative nugets exports, albacore/nugets_restore
- Plugins are pretty basic
- Plugins should get more than just the initial JSON, but also information from dependency nodes
- Chains of plugins might not work, due to BUILD file parsing order
- Ideally, all nodes are parsed in dependency order (rather than file order)
- This is partially implemented.
- We should not have to explicitly download code not being modified in the current client.
- Directories can maybe be mapped to git/svn/etc repositories on the web, and seamlessly integrated (maybe via a readonly FUSE mount).
- "third_party" is currently very large (includes boost, amongst others), and we should only have to cache files actually used for compilation locally.
- See Distributed Source
- We expand node input files in repobuild's input step. E.g. the '*.h' files for a cc_library get checked by repobuild.
- Some of these files might not exist until after dependent rules have run (e.g. protobuf generation).
- We currently do not match against dependent rules' "outs".
- Current hack is to set generated input files as $GEN_DIR/path/to/dep/file, and strict_file_mode_: false.
- Ideally, "path/to/dep/file" would look in "outs" as well as source tree.
- We have very few.
- Currently this whole thing generates a makefile.
- Limited distributed build works for c++ using ccache and distcc (configured separately)
- In an ideal world, it would act as a client funneling build commands to remote workers when the local CPU is tapped out.
- Eventually it will require cloud compilers/script runners with VMs (if a service) and a host of crosstools.
- This would allow public compilation caching for shared libraries.
- Xcode project files (mac)
- Visual studio project files (windows)