coapp-developers team mailing list archive

[Gordon Schumacher <whiplash@xxxxxxxxx>]

On 4/12/2010 12:23 PM, Garrett Serack wrote:
>
> I’ve been taking questions as to how CoApp packages get built.
>
> Lemme see if I can sketch out the vision for you, so that you get an
> idea of where it’s going. This isn’t set in stone, but I’ve actually
> validated this is a workable solution.
>

So, here's an alternate concept, albeit a "conceited" one, since it is
modeled after what I did for that toolchain, and then extended to how I
would have /liked/ to have done it.

Ideally, we need a solution which does not require "independent"
maintenance. The open-source community's frequent refusal to support MS
tools has been primarily that it requires completely separate build (and
frequently code!) from anything else; nmake's syntax is simply too
limited to accomplish much, and cl cannot easily do dependency
generation. (The other notable reason will not be overcome, which is the
"zealots" who refuse to go near anything that's not absolutely 100%
free/libre, and quite frankly I have very little use for zealots of any
stripe.)

IMHO there is not presently a good replacement for autotools, much to my
great chagrin; CMake comes closest, but quite frankly the syntax is
grody, and if you are attempting to do something that "they haven't
thought of", you're in for a great lot of pain. So I personally think
that the world is ready for a replacement build tool.

The obvious reason for resistance to changing build systems is that it's
a great lot of work. Now, my idea doesn't address autotools very well
"yet"; but I even have some thoughts there.

I come from a very heavily object-oriented and modular-code background,
so of course I am using this model for my concept here. My thought is to
write a very generic "build tool" core, which has no concept of makefile
language/format, compilers, or any such things - it has only the concept
of an Item which you run a Tool on, in order to produce another Item. At
that point, you may define Tools and group them by (for example)
product, processor, version, and so on ("this is a compiler for MSVS9
x86"). You also tell it what it consumes ("C++ source"), and what it
produces ("object files").

Then you would add plugins for different input and output formats: for
instance, I have done a lot of work with Qt's qmake, and am very
familiar with its source code. It would be fairly simple to use some of
its source files to build it as a plugin library instead of an
application. Also, the folks at Trolltech/Nokia have started a project
called "jom", which is an nmake clone - so there's already an open nmake
parser written. Studio projects are (mostly) just XML files, which are
easy to parse - and Studio has given us an API to do it as well. The
input formats would have a façade layer to convert the script into Tools
and Items and such. Then, you also have output plugins - for instance,
the obvious one is "go run the build", but writing a Studio project à la
CMake or qmake is fairly simple - and if it can also write its "native"
build language, then suddenly you have a build system converter!

Basically, this would make it much, much simpler to "port" a build
system; I am aware that it would not be a 100% automatic job, but if the
community produced something which was a serious replacement for
autotools - e.g., it cleanly handles system interrogation,
cross-compilation, etc. - then it would get adopted, particularly if it
wasn't a Herculean task to adopt.

I am still formalizing my designs of such a thing, but I have written a
requirements document (which still needs some cleaning up). I also
realize that this is not a small project - but I firmly believe that the
benefits of having such a tool are solidly worth the work!

Absolutely please try and pick this apart - I'm always open for
constructive criticism, and I certainly do not believe I have All The
Answers(tm).

I also have started a build-related blog at
http://www.valleyhold.org/blog/build, partially to capture my reasoning
for my design, and partially (in all fairness) to give myself a forum to
rant about why I believe most of the current options are either
inadequate for many things, or just downright broken! (I didn't say that
I wasn't opinionated - just that I'm always open to changing those
opinions!)