CEGUI (Crazy Eddie's GUI) Forums

Hi,

Coming back on the compile issues I had earlier on with the cvs checkout: I see that the same applies to the tarball (it includes bootstrap)

I've been told a tarball shouldn't contain bootstrap etc.
This is bad because: A user should be able to do ./configure && make && make install after unpacking the tarball. Forcing the user to have autotools installed could cause lots of problems if the version differs from the developers'.

Probably better to run bootstrap and include the "compiled" makefiles en configs in the tarball before release..?

Bye,
Alex

The 'release' tarballs are effectively snapshots of stable cvs branches, and they have had ./boostrap pre-run on them. And you can do ./configure && make && make install as you state. However...

As I understand it, _mental_ made a slight mistake when packaging 0.3.0, and we ended up including some symbolic links instead of copies of the actual files - a simple mistake that anyone could make. (The 0.2.0 releases were good in this respect, for example).

Anyhow, coming back to why all the files are included (including the CVS control files), basically you are all guinea pigs and we are using you to test the system - we want you to submit patches and update to the latest fixes committed to your stable branch of CVS - having all the files in the packages makes this more simple. For example, when you have all these people who keep reporting the same issues which were fixed over six weeks ago, it's useful when they can just do 'cvs update' and get these fixes without having to wait for us to put out a maintenance release (which we are no longer doing for the forseeable future anyway).

As for being told what a tarball should and should not contain, I really couldn't care less - we'll put whatever we want in them

For future releases, hopefully, we will catch mistakes such as the symlink issue though

heheh, fine by me, all that.. you should certainly do it your way, I know you're all skilled developers and cegui is great and all that..
it's just that when another skilled developer makes a comment on such a thing I always like to relay it and get some info on why certain things are done... since I am not that skilled in linux..
I thought it might help for the next release. A guinea pig spouting feedback! Who'd have thought..

We encourage feedback from all our guinea pi.. err.. I mean users

Sometimes my replies to feedback are taken as being too harsh, however I'm glad in this instance that the reply was taken in the light-hearted manner intended