jmmv ([info]jmmv) wrote,
@ 2004-12-01 16:49:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Buildtool status

Hmm, Buildtool... one of my pet projects, probably the one on which I've spent the most time working... and it was even starting to get some (few) popularity lately

But I must admit it. The code is, in its actual form, dead :-( It's unmanageable (shell scripting doesn't scale, you know) and breaks in many, many places. Just consider the following facts:

  • Detection of C++ features from bt_config fails in many cases.
  • bt_logic's behavior is less than acceptable, and adding functionality to it is a PITA.
  • Several modules haven't been modified across versions, so they don't work properly. For example, bt_lint is almost useless.
  • Shared library handling is broken in many systems, and fixing it could be very difficult.
  • The code exposes internals too much, specially in environmental variables and C/C++ defines. But cleaning that up is also complex due to the nature of shell scripts.
  • I was suggested recently to make bt_dist only include in tarballs what was really needed, and not everything (just like GNU Automake's make dist does. I like the suggestion, but implementing correctly is impossible due to the current code.

... plus a large etcetera. All in all, too many problems that can't be solved without doing very gross hacks or restarting the project from scratch. This is why I haven't touched the code since the beginning of the summer.

But... you know what? For some reason, I'm willing to rewrite it from scratch. Of course, using a real programming language. The choices I have in mind are ("obviously" ;-):

  • C++: I really like C++, together with the STL. Yes, believe me! It simplifies programming a lot, and OOP is wonderful. But I'm a bit afraid of portability. If I use this, it must follow the ANSI standard (not doing so could be silly), which means that users will need a compiler that follows the standard, such as GNU GCC. This is not a big problem, since GCC compiles almost anywhere, but may add problems to end users. However, by the time the program is usable, the situation may have improved a lot, hehe.
  • C: Very portable, assuming you know where the portability problems arise (not a big problem for me). But what really bothers me is that it slows down development a lot: I'd have to create my own classes to handle containers (hash tables, linked lists, etc.) and handle dynamic memory even for trivial tasks. I'd also loose polymorphism, inheritance, exceptions... Ok, ok, GNOME emulates OOP in C, but I'm not too keen on that.

If I can't find any strong reason not to use C++, I'll stick to it. In fact, I've already written a bit of code (program detection) and it has been easy :-)

Oh, I listen, "How could build scripts be?". Well, I have XML in mind - something similar to Apache Ant. Otherwise I'll have to invent and write a parser for a custom language (ew, not funny). But that's something yet to decide.



(Post a new comment)


(Anonymous)
2005-05-05 11:06 am UTC (link)
Hi Julio,
i thought that i have to post a comment to encourage you to continue your project. I am the founder of the PMK project which is another alternative to auto tools. In fact, from the few lines you written it looks like you're going to do something really similar to what i've done since 2 years, so i'll be glad to share my experience if it please you.
I think that providing alternatives to auto* tools is a good thing as many people are whining about them. This is a hard work because there is a great pression on those projects and also on other projects that want to start to use them. For example i've been informed that one of the project that was using pmk has stopped because the users didn't want to have to install pmk (sure installing autoconf is much more funny).

Anyway, i wish you the best luck and as stated above feel free to contact me i you have any question. By the way now i'm thinking about it, it could be nice to start to make a standard for such tools. Are you interested in this ? We could have two project supporting a such standard.

Damien

(Reply to this)(Thread)


[info]jmmv
2005-05-08 06:09 pm UTC (link)
Thanks for your comments! I have spent a lot of time in this project in the past, and I really would like to retake it at some point in the future (hopefully not too distant).

Having got to know quite well the auto* tools, I can say they are quite good, but still have some problems that won't be ever solved (the ones that made me start Buildtool in the first place). This is another reason why I want to continue with my project.

About the standard you propose... What exactly could it standarize? The file format, the command line...? It seems to me that each of the existing tools has very different goals and/or functionality in mind, hence a "standard" could be difficult to achieve.

At last, congrats for PMK. I haven't tried it myself, but when I read the docs, it seemed interesting; and it's good to have another alternative to the auto* tools. Plus it is still alive :)

Cheers,

(Reply to this)(Parent)(Thread)


(Anonymous)
2005-05-12 11:07 am UTC (link)
Well by standard i mean the process done on the files at the end of the configuration tests. What i'd like should be to be able to switch between autoconf, buildtool and pmk with the minimum of changes in the sources.
This changes should only affect the files needed by the configuration tool (like for example configure for autoconf or pmkfile for pmk). And files like Makefile.in or config.h.in will remain unchanged.

All this stuff would have two advantages. The first developers could switch from one project to another to follow their needs. The second could be that a project could provide files for many configuration tool and then let the user choose which one he want to use (for example as a matter of security).

Damien

(Reply to this)(Parent)


(Anonymous)
2005-05-12 07:32 pm UTC (link)
BTW i agree with you, autoconf is ok with their goals but there are now many people who don't share the same point of vue :)

IMHO it's too bloated because it handles too many platforms. That also why i started pmk like you did with buildtool.

The project is still alive but i got difficulties to find enough time to work on it. For example i'm actually working on the makefile generation from sources scanning. The C file scanning is working quite nice and i got a mostly usable makefile to build pmk itself. I'm actually adding stuff to also detects man pages and documentation for the install.

The worst part is that it's difficult to change minds, even for the people who ask for autoconf alternatives. They want advantages without counter parts : what a dreamm :)

Damien

PS: i was a bit in a hurry for the previous reply :)

(Reply to this)(Parent)(Thread)


[info]jmmv
2005-05-22 09:59 am UTC (link)
The project is still alive but i got difficulties to find enough time to work on it.

Heh, the same that happened to me :-/

BTW, WRT your previous reply, saying that your "standard" could try to homogenize how Makefiles are created so one could switch between programs easily... well, the thing is that in Buildtool, I abandoned make and created my own utility. It was quite a mess because it's all written in shell script and has some problems. But if I get to rewrite Buildtool, I'll still create my own make replacement (based on XML, as I said in the original post).

Cheers and sorry for the delay in replying.

(Reply to this)(Parent)(Thread)


(Anonymous)
2005-06-02 08:53 pm UTC (link)
I was speaking of a standard only for the configure tool. In my mind it means defining specific tags that will be used in a precise way. It would also include how the substitution will be done, etc ...

Speaking of make i'm also thinking about a replacement but i do not plan to remove support as make is part of POSIX specs and also an historical unix tool. But this is another story :)

Sorry too for the late reply, i'm in the process of moving to a new flat so i'm more busy than before. But hopefully it will be finished not so long ;)

I'll try to write something that looks like a beginning of standard and if you're interested then i'll send it to you.

Damien















(Reply to this)(Parent)


Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…