CBoard Community Project: Poll #1

[matsp]

Ok, you're right - but we should support this automatically for common things like debugging symbols, optimization and profiling.

How do you propose we do that? Which compilers do we choose to support? Just MS and gcc? Which version(s) do you suggest we support? What do we do for the NEXT version of compiler, where it has changed some feature?

One solution would be to have a level of indirection for the compiler settings, so that you do something like:

compiler = gcc
optimize_a_bit = -O2
optimize_a_lot = -O3 
optimize_no_fp = -fomit-frame-pointer
debug = -g

compiler = cl
optimize_a_bit = -O1
optimize_a_lot = -Ox
optimize_no_fp =  -Oy
debug = -ZI

--
Mats

[Brafil]

like that. We could use functions like "Compile("main.c")" instead of steadily repeating "$(CC) $(CFLAGS) main.c" or "Link("program")" instead of "$(LD) $(LDFLAGS) <all object files> -o program".

Anyone can add support for a new compiler, yet I don't know how.

AddCompiler("very-strange-compiler", 
    optimize_a_bit="§optimizealittle", 
    optimize_much="§speedisallimportant", 
    debug="§iwilluseadebugger", 
    output="§iwannausefile $output")

Where "$output" is a placeholder.

And if a version is different, we should be able to replace something.

AddVersion("very-strange-compiler", "999.999", 
    profile="§helpmespeedupmycode")

Then, we use simply:

Compile("file.c", optimize=a_bit, profile=yes)
...
Link(strip=yes)

and this will result in an error if "very-strange-compiler" is being used in a version < 999.999, since it didn't support profiling.
Of course there are some problems like detecting the correct version etc. but it would be more portable and easy-to-use.

[Snafuist]

We can get rid of this discussion by a data-driven approach: for each target compiler, we have a configuration file, e.g. gcc.conf and msvc.conf.

These config files share a common set of language configuration items and their respective meaning, i.e. gcc.conf might look like this:

Optimization = '-O1'
MoreOptimization = '-O2'
InsaneOptimization = '-O3'
...

and msvc.conf looks like this:

Optimization = '/whatever'
MoreOptimization = '/it looks like'
InsaneOptimization = '/in MSVC'
...

This way, the user only needs to specify the target compiler and some options like "Debugging", "NoProfiling", "InsaneOptimization", and the build system will choose the proper compiler and options.

Greets,
Philip

EDIT: hmpf, matsp was faster again.

[Brafil]

Yes. Either this or we used a startup file including default compilers. Great idea, huh? xD

[Snafuist]

As for the language, I suggest an object-oriented approach with as few types as possible. With respect to the build system, a good type seems to be "set of files". I'll give an example rather than explaining it in detail, trusting on your ability to figure out what I mean:

@fs.add("foo.c", "bar.c", "baz.c")
@fs.dependencies("snafu.o", another_fs)
@fs.set(NoOptimization, Debugging, Profiling)
@fs.compile()
@fs.link()

This approach definitely needs more thinking, but I like it so far. Scope is simply defined per object, so we don't need to care about that.

Greets,
Philip

[Brafil]

Good. But I didn't like the '@'s. They're too perlish. We could create a module interface, so file-set doesn't need to be built-in.

Don't forget:

@fs = fileset("directory_name")
...
@fs.output = "output"
@fs.strip = true/false (yes/no)
@fs.compile()
@fs.link()

And I think you should drop @fs.set. Just set @fs.optimize/debug/profile to true/false. (Or an integer for optimization, like 0 (no optimization, automatically set by debug), 1 (not much), or 2 (sharply optimized))

[MK27]

As for the language, I suggest an object-oriented approach with as few types as possible.

We should analyse the pros and cons of existing languages. Then we should decide the paradigms (procedural, functional, object-oriented, imperative etc.), after that we can move on to syntax. Later on, will it be bytecode-compiled or not? Extensions? Garbage-collector? At last we should bring everything together with a standard library. Voila, a basic language. Then we could add libraries to extend it into a build-system language.

Here's a few cents from my current study of ruby, where everything is an object, including numbers. I thought that was silly until I saw this

5.times { puts "hello" }

which really does seem 1) simple 2) elegant. Also, there are no functions -- just method calls. This starts to seem very clever in an "embedded in html" context.

So since we are performing a specialist task, I think we could do a little more thinking about that task in relation to the fundamentals of the language than just saying it can be dealt with in a library. Maybe so, but this could be the difference between something that is phenomenally great and something that could be, at best, just "well done". AFAIK ruby was not (quite) designed intentionally to be embedded, but it lent itself to this very well and so got picked up for the task. Point being, it is still a very good general purpose language a la perl.

I can't say what this would mean in the built tool context, which I've never had to give much thought to. Just hoping to spark some weird idea in one of you geniuses. Also, the "everything is an object, no functions just methods" is a potential model.

[Brafil]

Well - I personally hat that aspect of ruby ("x.times", "x.each do |i|"). It's a matter of personal preference.

And I think functions and methods should be seperated, e.g. a module shouldn't have methods, just contents, which can be functions (not like in python). That is also my approach in Ascent.

And object-orientedness is quite popular today. Yes, most OOP-languages think of things as objects. That could also be an approach.

[matsp]

Yes. Either this or we used a startup file including default compilers. Great idea, huh? xD

But it is hardly a novel concept. Regular makefiles already do this to a greater or lesser degree depending on the needs, intentions and imagination of the author. Your autoconf case doesn't fail because autoconf isn't able to do this, it fails because the author of the SPECIFIC autoconf script didn't supply enough flexibility to allow a switch from gcc to MSVC or vice versa.

--
Mats

[Brafil]

Yes. Our job shall be to make exactly this easier.

[MK27]

Well - I personally hat that aspect of ruby ("x.times", "x.each do |i|"). It's a matter of personal preference.

And I think functions and methods should be seperated, e.g. a module shouldn't have methods, just contents, which can be functions (not like in python).

My point was NO IT IS NOT A MATTER OF PERSONAL PREFERENCE. By coming up with concrete reasons related to the concrete task rather than just making it a matter of off the cuff personal preference, you will be far more likely to come up with something insightful and dynamic in context.

Otherwise you are just saying, "every time I make a language, it will be more or less the same because of my personal preferences". If you use those preferences instead of the context, you are selling yourself short.

For example:

And I think functions and methods should be seperated, e.g. a module shouldn't have methods, just contents, which can be functions (not like in python).

Being only passingly familiar with GNU make (and totally unfamiliar with any technical description of the language it uses*), I would say this is kind of like a set of function calls:

all-am:    all-modules
              all-doc
all-doc:    make manpages
              cp README, NEWS, etc

But would probably be better seen as a set of object methods.** That said, you do not actually need functions (again: ruby is fully functional but does not use them). So yeah, I am advancing the idea that this would be a good way to go here too. Snafuist points out something similar earlier in the thread altho he may not agree with going to such an apparent extreme.

It would be easy to change my mind, of course, but not just by saying "I would prefer it such and such a way" without any in context justification. Otherwise you might end up doing the entire project yourself

*I guess I could do some research...
**really I suppose this is just straight imperative "methodology"

[Brafil]

Yeah, I just meant what I said. all-doc etc. should be methods on e.g. the build state object.

[MK27]

Yeah, I just meant what I said. all-doc etc. should be methods on e.g. the build state object.

So, having functions *and* methods might just be an unnecessary complication.

[laserlight]

Just to clarify: we are basically settling on designing and implementing a small scripting language followed by a portable build system, right? What I am not clear about is if we intend to design this scripting language specifically for writing build scripts, or if we are designing it more generally, and then using it as the language for the build system's scripts.

EDIT:

So, having functions *and* methods might just be an unnecessary complication.

Yes, yet functions can come in pretty handy as an alternative to static member functions when you want to extend a class without using inheritance or composition.

[MK27]

Yes, yet functions can come in pretty handy as an alternative to static member functions when you want to extend a class without using inheritance or composition.

Could you provide a short pseudo code example of such a situation, and maybe elaborate slightly? It seems to me you could always use a method call from a predefined base/top level class (class class or class object or something) to circumvent a more specific inheritance model.