dasmithii / kit Goto Github PK

project manager for c/c++

License: MIT License

Python 99.41% C 0.59%

kit's Introduction

Overview

In contrast with many modern languages, C has no standardized systems of module distribution, dependency handling, or project management in general. From basic directory structure to build tools, everything seems fragmented. More so, libraries are inaccessibly scattered across the web - and that pressures developers to reinvent the wheel over and over again.

Kit is a potential solution to these problems. It provides standardized project structure, centralized module indexing, and a convenient build tool [which wraps CMake, capitalizing on standardization].

Installation

pip install git+https://github.com/dasmithii/Kit.git

or, without pip:

git clone https://github.com/dasmithii/Kit
cd Kit
python setup.py install

Sample Usage

Spawn a boilerplate project.

mkdir my-project
cd my-project
kit init

kit run is short for ./build/bin/my-project
kit test is short for ./build/bin/tests

Include kit modules.

kit build scans the source tree for lines that match #include <kit/*>, attempting to resolve each dependency. This is done by searching the local index, and if specified modules aren't found, by resorting to the central registry. Located modules are linked against, and their corresponding headers are added to the include path.

tl;dr: to include a module, #include <kit/module/file.h>.

Create kit modules.

To make code available locally, run `kit install'. If you feel that your code could be useful to others, send a pull request with edits to MODULES.csv. That file lists items in the central index.

Further Information

kit's People

Contributors

Stargazers

Watchers

Forkers

sylvia43 hhnr wangyinfeng gkotian mstls

kit's Issues

Typo in README

#include <kit/module/file.h

should read

#include <kit/module/file.h>

Added support for C++

With a few changes to builder.py, C++ modules could be supported alongside C modules, since these languages share the same compilation process.

Implement Kit-independent distribution

Libraries written under the management of Kit are hard to distribute, especially when these libraries depend on modules in the Kit index.

For C developers who aren't willing to adopt a new project manager, we should provide a kit dist command. This would fetch dependency sources, replace Kit-based include statements, and wrap everything into a [mostly] self-contained project.

CMake imported library being treated as a target, although it has no build rules

Version tracking and differentiation

At this point, modules are treated identically regardless of their version. This poses a problem when library APIs change and undermine existing codebases.

TODO

Prettify standard output

The output of Kit is pretty chaotic, especially when fetching modules from the central repo. We should clean everything up a bit a some point.

Kit fails to run after install

Traceback (most recent call last):
  File "D:\Python34\Scripts\kit-script.py", line 9, in <module>
    load_entry_point('Kit==0.1', 'console_scripts', 'kit')()
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 353, in load_entry
_point
    return get_distribution(dist).load_entry_point(group, name)
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 2302, in load_entr
y_point
    return ep.load()
  File "D:\Python34\lib\site-packages\pkg_resources.py", line 2029, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "D:\Python34\lib\site-packages\kit-0.1-py3.4.egg\kit\main.py", line 3, in
 <module>
ImportError: No module named 'commands'

Are there any dependencies that need to be installed to run Kit?

Slow startup

The upstart time for Kit is too slow. This isn't a bug, but it would be nice to speed things up a bit.

I think the primary cause is an overabundance of import statements. The code is organized in such a way that requires many imports in each module, which, according to this link, may increase startup overhead. Some refactoring might help. Lazy imports are another option (can they be made automatic in any way?).

Other potential areas of improvement:

the scanner and its recursive globbing of source files
makefiles in the context of parallel compilation (this might not help during startup, but it'll speed things up nevertheless)

Differentiate between C and C++ modules

C++ projects may link with C modules, but the contrary is not true, so there should be something to prevent accidental inclusions of C++ sources when only C sources are permitted.

Module name collisions are another issue.

Need way to specify compiler flags.

Some projects require libraries outside of kit, need specific versions of C, or do other important things that kit leaves unsupported.

An optional configuration file, maybe?