[Fractux]

I redownlaoded the fs2_source from CVS, but there's no 'configure' file now.

Just wondering what was going on.

Cheers!

[WMCoolmon]

Do:

./autogen.sh
make

[taylor]

You have to "./autogen.sh" first and it will be generated.  The ./configure script is system dependant so it's never supposed to be in CVS.

EDIT: bah, WMC beat me to it.

[Fractux]

Thanks guys

[castor]

Btw, this would be a good info to have in the 'INSTALL' file.

[taylor]

It's not needed for official releases though, only when you build from CVS.

Having to run ./autogen.sh is a standard from-CVS thing to do so that's not really something I want to explain in a readme or something.  If instructions on how to build from CVS are needed then I'd prefer that it got asked here or the person just didn't do it.  A CVS build is never guaranteed to work properly so you're always on your own unless we happen to be in a code freeze like we are now.  In a couple of weeks I'm sure CVS will be a complete free-for-all and lots of stuff will break.

[Fractux]

Well, i've been making new builds every 6 - 10 days or so and keeping all my old builds for debugging purposes.

I don't really use CVS other than building fs2_open, and I just completely forgot that initially I had run ./autogen - I had just kept using ./configure for my builds.

Just wondering if that would/could have any adverse effect, for future referece?

Cheers!

[taylor]

Originally posted by Fractux
Just wondering if that would/could have any adverse effect, for future referece?

Of using an old configure script you mean?  Pretty much nothing.  If you downgraded your autoconf tools then there would probably be an issue.  I use the same configure script pretty much always btw, so it's no big deal.

Really the only time you would want to rerun ./autogen.sh is if the configure.ac file got updated.  With some upcoming changes in the next few months that would be neccessary in order to still have a successful build.

[WMCoolmon]

I like the idea of a ./configure script better. Almost every time I've compiled from source it's been the usual ./configure, make, make install...throwing in an autogen.sh just seems to needlessly complicate things.

[taylor]

Originally posted by WMCoolmon
I like the idea of a ./configure script better. Almost every time I've compiled from source it's been the usual ./configure, make, make install...throwing in an autogen.sh just seems to needlessly complicate things.

That's just how it works, autogen.sh is there to make it easier.  In order to bootstrap you've got to ./aclocal && ./automake && ./autoconf before you can even ./configure.  autogen.sh just takes care of all of that crap for you.  It's just what you have to do to handle things properly with CVS.

The official tarball release (and any tarball release for that matter) will be created with "make dist" and in that case all you have to do is ./configure && make.  A tarball doesn't even include autogen.sh since it's not needed.  When you get tarballs from a website or something they are done this way.  Get the same code from CVS and you'll have to bootstrap in order to build.

[dizzy]

WMCoolmon: having a "configure/config.h.in" in CVS is the same as having a .o file in CVS ie it is generated from other source files (configure.in in our case), it will need to be updated when any of the source file change (so you update configure.in, you will need to recommit configure too) and it just beats the point of CVS, what whould be the point to have versioning on "configure" if it's generated from configure.in and it will be updated each time. Not to mention that the actual "diff" of changes between 2 "configure" commits won't make too much sense (as is an automatically generated very complex shell script) while a diff between 2 "configure.in" changes do make a lot of sense

As taylor says, this is only valid for CVS, ie for developers and CVS testers which both of them should know about this issues. The releases/distributions always include a configure/config.h.in.

Some other projects also provide a "Makefile" in CVS that just calls autogen.sh when you run "make" and as such it overwrittes this Makefile with the one generated from automake (called by autogen.sh)

[WMCoolmon]

Not to be rude, but I don't really care... it would certainly be possible to make an automated configure script that automatically runs autogen.sh, it could always call other scripts in turn.

Now that may go against Linux convention and all, but frankly, I care even less about that. To me what matters most is making it easy to get working, meaning either involving as few of steps as possible, or make them familiar steps that people will have likely heard of before. Massive, convoluted makefiles that are 95% identical to unrelated programs' makefiles makes no sense whatsoever. Something that constantly irks me when I'm compiling from source, because then I'll still end up with bizarre errors from missing dependencies during compiling, and half-baked error messages, so what was the point in the first place?

Anyways, I've seen the autogen.sh thing so it's not a big deal to me, just kind of a minorly annoying discrepancy.

[taylor]

Originally posted by WMCoolmon
Not to be rude, but I don't really care... it would certainly be possible to make an automated configure script that automatically runs autogen.sh, it could always call other scripts in turn.

autogen.sh is that automated configure script.  It's not named "configure" because it can't be as it would always get overwritten.  We can make this tremendously more difficult by not using autotools if you want (not going to allow it, just saying ) and require more work for developers to keep things working and/or more work for users to require them to install and learn new build tools.

autogen.sh already runs ./configure and can pass the same configure options even.  This isn't difficult, it's easy, and that's the point.  Anyone using Unix code out of CVS which makes use of autotools has to do exactly this same thing.  If the project doesn't make you bootstrap first then that project is wrong.  Period.

Going against Linux/Unix convention is actually what we can't do since it would piss off pretty much every Linux/Unix user.  That you don't like it has abosolutely no bearing on how it should be done since these aren't unfamiliar steps to Linux/Unix users.  People who aren't familiar with it just need to be told, 99% of people will already know.  Compiling from a tarball is "./configure && make && make install" and compiling from CVS is "./autogen.sh && make && make install".  Please explain to me why you find that so much more difficult.

Ignore the Makefiles since they are generated anyway and CVS ignores them.  Just be concerned with configure.ac and the Makefile.am files since they are all we need to mess with.  That's the point of autotools, to liberate us from managing the covoluted crap.

[Fractux]

Ack!! What have i started

In all honesty, as a newbie to linux and its development tools all I can say is that typing in (not even, thanks to the lovely TAB key) ./autogen.sh --enable-debug or ./configure --enable-debug takes the same amount of time for me, and produces the same results.

Cheers!

[WMCoolmon]

Well, I probably shouldn't have replied, given that I just had to reinstall Linux and deal with all the messiness that entails.

Generally I'm cynical about how convoluted typical linux scripts are. Windows is no better (With .NET it's actually a lot worse), but it's not as big of an annoyance to me as the GUI is better and more reliable than any program I've seen on Linux.

[dizzy]

Actually I have yet to find a Windows GUI that fulfills my needs but that is totally another discussion hehe