generalized language support, multiple files, capability signature

[gravitino]

1. Why not implement multiple file support by stacking the files into one file separated by specified delimiters. As an example:

BEGIN_SAUCE_FILE(foo.hpp)

ifndef FOO_HPP

define FOO_HPP

define N (10)

endif

END_SAUCE_FILE

BEGIN_SAUCE_FILE(foo.cpp)

include

include "foo.hpp"

int main () {
std::cout << N << std::endl;
}
END_SAUCE_FILE

Remarks:
(i) the splitting into the files should be easy (the inverse operation is also easy).
(ii) the syntax is human readable, the files can be stored without changes to the database
(iii) SAUCE could display the individual files to the user in different tabs
(iv) concatenation with submission ids ensures collision-free storage in any temporary directory

2. Define languages exclusively with the help of Makefiles. Dedicated targets like "preprocess", "compile", "run" and "postprocess" shall be used to indicate the tool-chain entries.

Remarks:
(i) a language definition is also a human-readable text file.
(ii) SAUCE could provide a zip file with the split files and the language Makefile to the user.
(iii) if appropriate compilers are installed, the user can simply build the project with make at home.
(iv) the tool chain is easy: split the files as described in 1. copy the Makefile and finally call the targets

3. Sign Makefiles with an appropriate cypher. This cypher can be used as unique capability identifier that can be exposed by clients of the future queuing system.

[moschlar]

1.

You can have that right now, if you need it, by using a wrapper script that performs the splitting.
For the "real" implementation, there will be no need for such hacky approaches - required database changes will be performed and all will be well and not hacky.

2.

I thought about this already, but I don't think it's appropriate in general, since the make system introduces a big load of complexity that doesn't necessarily provide the level of control I'd like SAUCE to have over the process.
But of course, it can be easily defined as a Language definition in the future or right now if you would like to use it.

3.

a) The correct spelling would be cipher - too much cyber in germany right now, heh?
b) I also don't think you mean cryptographical signing at all.
c) For the queueing system, there will simply be a queue attribute for languages: e4e062c#diff-0838c71a185fab5f25c1be36db8db61cR148