sierdzio/gibs

Experimental project: in-source build system. Just for fun ;-)

gibs's Issues

Add quick mode

When run with -q or --quick, ibs should only parse .h files up to Q_OBJECT (or gadget) macro, or (if none found) up to first private/protected/public declaration. In .cpp files, parsing should stop at first "real" code like a function definition.

Plus other optimisations you may find, of course.

Files referenced from include paths are not parsed

Let's say you have this in your main.cpp:

//i includes some/dir

Then in your source file you have:

#include "file.h" // <- file is located in some/dir

IBS fails to parse file.h.

Generate AppImage packages

ibs should be available for download as an AppImage.

Add ifdef support and scopes

IBS should understand #ifdef statements from C++.

The biggest problem with that are ifdefs from external libraries (like Q_OS_LINUX) - how to include them? Parse all included headers? That seems like a waste of time. This needs to be thought out.

Proposed syntax:

/*i
ifdef Q_OS_LINUX
  libs -Llinux/lib -lqzxing
else
  libs -Lwindows/lib -lqzxing
endif
*/

Or (for OSes) something like:

//i platform linux libs libs -Llinux/lib -lqzxing

Add deployment to AppImage

ibs could automatically use (provided) linuxdeployqt to create ready Linux packages.

Add Qt modules support

It should be possible to easily support Qt with something like:

//i qt core network

Add library template support

IBS should be able to produce both applications and libraries

Allow debug and release builds

Quite obvious, isn't it? Currently gibs only builds in debug mode.

Proposed syntax:

gibs --release main.cpp
gibs --debug main.cpp

Which should be the default? Most probably the release build.

Comments and docs

While the Readme is fairly up to date, ibs is severely lacking comments and doxygen docs.

Add module support

If, for example, a header includes something from ../other_dir/, we should be able to add that path to include paths. Much like INCLUDEPATH works in qmake.

Syntax:

//i include ../other_dir
// Or
//i module ../other_dir

Or something.

Allow out-of-source builds

IBS currently gets confused if it is not run from the same folder as the source code. That's bad.

Support concurrent build

IBS should use all CPU cores / threads by default. It can be modified using the traditional -j X flag.

Hook up to MLog

We have it but don't use it... let's change that :)

Use categorised logging

From Qt.

Hard scoping support

ibs can theoretically strictly control which -I includes and -L library includes are needed where - and not use them for every compilation and linking step. Make it a reality. This could potentially speed things up.

mkspecs parser

qmake's mkspecs are a splendid source of ready-made environment configurations. It would be cool if gibs could tap into it.

Assume project name is root dir name if no target name is specified

As the title suggests. Currently the default project name is "default", which is lame.

Support all IBS commands on the command line

So that it is possible to define everything outside the source code.

Proposed syntax:

ibs -c "qt core; defines MY_DEFINE"
// And
ibs -c config.file

Pipe data into compiler

Since ibs is already reading all headers and sources, it is a waste for compiler to do the same again.

Add an option to cache the file and then pass it to compiler via pipe.

Help: https://stackoverflow.com/questions/1003644/is-it-possible-to-get-gcc-to-read-from-a-pipe

Add deployment support

This needs to be thought out first

Feature support

Features are optional, compile time functionalities which can be turned on or off.

Internally they can be just subprojects of type zero: they don't produce an app or library, just provide include files and sources. Feature also adds a define for the compiler.

A feature can be turned on by passing --some-feature to ibs. Feature can be turned off with --no-some-feature.

Make sure proper relative paths are maintained.

This is to make sure we have solid build foundations + we are able to handle 2 files with the same name, like:

- header1.h
- something
|--header1.h

etc.

Support incremental builds

Running ibs again on already-compiled project should run very quickly - only changed files should be parsed and updated.

Add config files

Config file (located either in current dir or $HOME/.config/) could hold useful paths, like:

• Qt dir
• Android SDK path
• Android NDK path
• Android APIs
• etc.

Add Qt module autodetection

Syntax:

//i qt auto

IBS will guess required modules based on include file names.

Remove Qt dependency

Well, although I admit it with sadness, a proper build system should have as few dependencies as possible. So, if possible, gibs should be compilable with just standard library (plus maybe some minimal JSON lib).

Add clean step

IBS should be able to clean up after itself. Syntax:

ibs clean

It should clean all build artefacts.

ibs purge

This command should also remove all remaining ibs files (caches etc.).

Accept floating point job number

If -j 0.5 is specified, ibs will use half of available CPU cores.

The "normal" option remains the same: -j 5 will limit ibs to 5 cores.

Incremental builds - handle moc

Make sure that MOC is re-run when a Q_OBJECT header is modified.

Automatically scan include dirs

Directories below input file are likely to contain project code - we can add an option to scan them automatically (with corresponding command line flag).

Add custom LIBS support

Users need to be able to define dependencies (libaries), much like LIBS in qmake.

Proposed syntax:

//i libs -Lsome/path -lname

Subprojects

Ibs should be able to handle multiple targets.

And it should use it's system of only waiting when absolutely necessary to speed up module compilation.

Modules

Gibs could have a notion of a Module: a defined package (usually a library) that can be included easily into other C++ applications (also build using gibs). An application could specify:

//i import path/to/module.gibs
// or
//i import github.com/user/repo.git

Seeing this, gibs would automatically parse the module and include necessary headers and libraries (if any). When pointed to a remote repository, it would first clone it and then do that work. In this sense, modules could be similar to how Go language works.

The actual module would be just a regular gibs project. No special syntax is necessary. At least initially, because we would need to introduce some versioning etc.

Add Qt tools support

MOC, RCC, UIC and others.

Proposed syntax:

//i tool rcc resourcefile.qrc