cboard community project

[MK27]

Yeah... I see how terribly some programs can be. But what about the poll? [/impatiency]

Should we just skip the pole and go with the "build system" concept (speak now or forever hold your peace)?

[Brafil]

I don't know. I'm happy with make/autoconf. And there are so many great ideas out there, we just don't know where.

Just tell what you're thinking about.

I think one main problem is that few people are looking further than Linux Programming.

[Snafuist]

I don't know. I'm happy with make/autoconf.

I don't really like make and I hate autoconf, so personally I'd be happy to come up with something "better". In this case, it won't even be very hard. The build system has many advantages apart from its actual purpose: there are large parts that can be implemented by beginners, we can have an in-depth design discussion as the basic concepts are known to everyone in advance, and we have a large user base (the programmers working on it) that can test the software while it is being built.

And there are so many great ideas out there, we just don't know where.

Well, what are your ideas? :-P

I think one main problem is that few people are looking further than Linux Programming.

The build system is surely not Linux specific by its very nature.


But I'm open to just about everything that is related to programming.

Maybe we should start a more brainstorming-like approach. Just throwing in random ideas without immediately starting a discussion about it. What do you think?

- C library of standard data structures (graphs, trees (AVL, binary, (a,b), splash, red-black, balanced, ...), hashes (with all those funny hash functions), lists (single, double), dynamic arrays, circular arrays, heaps (Fibonacci, Min, Max, ...), treaps)

- C library of standard algorithms (shortest paths, tree traversal, finding min/max, min cut in graphs, hamiltonian, eulerian, searching (linear, binary, ...), sorting (heap, quick, merge, bubble, ...))

- C library to encapsulate the networking functions. I especially envy the Plan9 dial() system call, which altogether replaces socket(), bind(), listen()/accept(), ...

- some kind of networking client functionality, e.g. a good IRC protocol API (there are exactly 0 available)

- yet another distributed file sharing system

- yet another suite of exploits

- a microkernel (which is probably a nasty idea... kernels are hard to debug)


Greets,
Philip

[Brafil]

I think your examples are fine, while not necessarily good. A Library on data structures? Anyone can follow some tutorials, and the point is in learning to determine when to use what, not how. Algorithms are the same. Networking is a bit too boring (IMO). Microkernel? That seems hard.

PS: My ideas are found in this thread <-

[brewbuck]

My vision of the build system would be a simple program (only several source files, if that) which could be distributed as part of a larger project, and could itself be built by a standard build tool (GNU make on Linux, nmake on Windows), which could then be used to build the enclosing project.

Maintaining two small build scripts (to build the build system itself) is far easier than maintaining two huge build scripts to build the surrounding project.

For inspiration, look at something like Jam/Boost.Build, but that system is enormous. I'm thinking something simpler but along those lines.

[brewbuck]

Like I said, I have no strong opinion on the project. I do like the build system. Brafil, if you want, go ahead and do a poll yourself with some of the options that have been presented here. Just make sure the build system is on the list.

Nothing needs to be set in stone. We have a server now (I'll be poking around on it this evening I hope), so we could host as many projects as we'd like (within reason -- the point is to work on something together as a group).

As far as SCCS, I think the decision is already made that we'll be using SVN for now.

[MK27]

Looks like we need a poll then. How's this idea:

Everyone interested has until noon tomorrow (GMT) to submit an idea to this thread. ONE IDEA PER PERSON, MAX. Then we throw all the ideas into a open poll and that lasts another 24 hrs. "Open" meaning your vote will *NOT* be anonymous, and you cannot vote for your own idea, and your vote does not count if you did not indicate a previous interest*. Then, if there is a tie, the people who voted for non-candidate projects resolve the tie. This will ensure we maximize the degree of consent and approval.

Or, we can just keep brainstorming...

*so, you don't have an idea, you just have to tell us you are interested before noon tomorrow (GMT). I'm willing to stand up right now and say my idea is a 1st person "shooter" perspective animated 3D filebrowser -- but I cannot vote for my own idea...

[brewbuck]

I'm not sure why we shouldn't be able to vote for our own idea -- is it because the voting pool is so small?

[Cactus_Hugger]

What is this about not indicating a previous interest? I've been sharking this topic the whole time - I've just not had any useful input to give yet. (Though I'm interested in this project, and wouldn't mind contributing. Consider my previous interests indicated.)

The build system sounds interesting... there's really quite a lot lacking in make, cmake is better but still has some issues.

[whiteflags]

I don't really know how build systems work at all.

[Snafuist]

I don't really know how build systems work at all.

I think their main purpose is to annoy users concerned with portability.

I also don't know much about build systems. Either the stuff I do only requires a single call to gcc, or I generate the necessary scripts automatically. A few months ago, I've been reading the GNU autoconf manual, but I didn't do the examples so I'm about as clueless as before. I see this as an opportunity to gain experience in different build systems, possibly including our own.

Good morning from Germany,
Philip

[zacs7]

There's not much too build systems, but there can be, that's the beauty of the idea.

Oh and autoconf and friends suck :-)

[MK27]

Did I say GMT? Anyway, from the looks of things, we REALLY don't need a pole. Glad to see there's more people poking their head up too.

I totally empathize with Snafuist on this; as a programmer, I don't really "like" build systems and use them as little as possible. But as a linux user, I appreciate GNU make, since I prefer to build software from source and linux stuff generally comes nicely packaged in an autotools tarball with an autoconf'd "configure" script.*

So I see this as a great learning opportunity. I think next, the people who are most informed and interested in the build process need come up with a clear statement about what the goal is, and perhaps give the rest of us something to think about.

No one came forward and claimed the idea for the pole, so I'm gonna stick it on zacs7 and brewbuck. What's up guys?

*That system works tremendously well, and there is exactly ZERO chance of anyone providing a serious alternative IMO, b/t/w. But I don't think that is what brewbuck had in mind.

[brewbuck]

No one came forward and claimed the idea for the pole, so I'm gonna stick it on zacs7 and brewbuck. What's up guys?

Just haven't had time...

*That system works tremendously well, and there is exactly ZERO chance of anyone providing a serious alternative IMO, b/t/w. But I don't think that is what brewbuck had in mind.

I hate configure scripts. I have seen projects where the configure script was over 10 times as long as the source code of the actual project, even if the project had no special dependencies.

A build system should not require configuration except to point at dependencies. We don't need a program which reads a meta-template which generates a Makefile template which is variable-substituted by a 10,000 shell script to become a makefile which then becomes the input to make... No, we don't need that. :P

[MK27]

A build system should not require configuration except to point at dependencies. We don't need a program which reads a meta-template which generates a Makefile template which is variable-substituted by a 10,000 shell script to become a makefile which then becomes the input to make... No, we don't need that. :P

Perhaps this is why "as a programmer" I don't like the looks of it. You have to use GNU make with kernel modules (but not autotools et al), and a 2 line make file to compile 50 lines of code into a single, stand-alone 6k module binary also produces about 50k of other files -- seven or eight of them and a directory.

I have absolutely no idea what is going on with that, but it looks like I'm about to learn...