[ODE] documentation initiative

[J. Perkins]

Adam D. Moss wrote:
> Hey, this is cool, thanks for pointing out (&writing :)) premake.
> In this long term this might evolve into something we can use as
> the preferred way to maintain the ODE build process... I'll keep
> my eye on it. :)

Yes, it is definitely not ready for primetime yet. It does seem to work 
well for the windows IDEs, but the gcc makefiles could use some work.


> 1) How do we properly integrate the bizarreness of configure.exe
> into the premake process?  

The idea of manually maintaining config.h, instead of using configure, 
has been floating around the list for a while now. I decided to get the 
ball rolling. However, it is certainly possible for premake to kick off 
a few compiler runs and parse the results, and when I get a chance I 
will look into that.


> pass/fail C tests -- perhaps Premake could gain the ability to set
> build flags depending on the result of compiling and running sets of
> C snippets, but then it's turning into Autoconf...).

I don't see any reason why it couldn't do just that. I'd have to think 
about it though.


> 2) Premake's Makefiles are for GNU make... I *think* we've otherwise
> avoided requiring GNU make for ODE (except ironically on win16??),
> but that's probably a fairly minor issue.

Ah yes, it's a bootstrapping issue. Premake will make build scripts, but 
who makes build scripts for premake? At the moment, it generates it's 
own makefile which is why it is so complex. There is really no reason 
why I couldn't use more generic version. I will look into this also.


> 3) Not really an ODE issue, but I wonder whether Premake could
> ever emit recipes for cooking foreign files, for example
> .lua -> .luac 

I think that this should be possible. For makefiles certainly, but I'm 
pretty sure all of the IDEs can handle custom build commands. Someone 
has already requested pre- and post-build commands, perhaps I can try to 
do it all at once.

> 4) Premake needs time to mature a little, perhaps. :)  For me:
> 4a) Premake 1.8 doesn't build as C without the attached patch

Thanks for this, I will apply it for the next release.

> 4b) Premake 1.8 generates its .d file in the wrong place (all in the
> project root dir)

What would be the right place? I'm a windows guy, really :)


> 4c) Premake-1.8-generated Makefile fails to link Premake 1.8:
> Linking Premake
> /usr/local/i686-pc-linux-gnu/bin/ld: cannot open output file ./: Is a 
> directory
> collect2: ld returned 1 exit status

Whoa that snuck by me. Well, I'll take this as motivation to write a 
simpler makefile. I'm not too familiar with the make variants, but I'll 
try to keep it as generic as possible.


> Looks promising though.

Thanks. I'll post back to the list when I've had a chance to do 
something about your suggestions.

Jason