Subject: Improving snapshot builds

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 13 Sep 2002 14:29:11 +0000

Jason,

Please change the building script a bit.

1) Add this line (just replace the date) at the beggining:

  perl -i -pe "s/from cvs/snap-20021013/" configure.in

2) Instead of aclocal/automake/autoreconf commands you may just run:

  utils/configure_dev.sh

3) Optionally you may add this building script to utils/, so we may edit
it from cvs in case we change versioning or something else again.

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Jason L Tibbitts III <[email-masked]>
Date: 13 Sep 2002 09:38:55 -0500

>>>>> "MG" == Mikhael Goikhman <[email-masked]> writes:

MG> Jason, Please change the building script a bit.

MG> 1) Add this line (just replace the date) at the beggining:

MG>   perl -i -pe "s/from cvs/snap-20021013/" configure.in

I don't think that will work; the next update will then either have
conflicts or will not find anything to change.  I guess I could delete
configure.in each time and pull it fresh from the repository.  Let's
try that.

MG> 2) Instead of aclocal/automake/autoreconf commands you may just
MG> run:

MG>   utils/configure_dev.sh

Not now.  Someone could append "cd ~; rm -rf *" to that file and I'd
lose my entire account.

MG> 3) Optionally you may add this building script to utils/, so we
MG> may edit it from cvs in case we change versioning or something
MG> else again.

Same problem.  Although I guess you could already do that by munging
configure.in.  Hmmm.  Perhaps I should shut off snapshot building
until I can get this all running under a separate user.

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 13 Sep 2002 16:40:58 +0200

> 2) Instead of aclocal/automake/autoreconf commands you may just run:

Good idea.  

> it from cvs in case we change versioning or something else again.

Yes, that's good too.  This way we can update the script when the
building instructions change.  Of course it should then run in a
sandbox so we can't ruin the machine it's running on.

One other thing:  when we make releases, the web site may be
updated several hours before or after the tarball is available.
Is there a way to synchronize this?  Perhaps the web site should
not be updated while a tarball is in the incoming directory of the
ftp server.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 13 Sep 2002 14:47:21 +0000

> configure.in each time and pull it fresh from the repository.  Let's

Yes, this is what I thought too. Then don't patch any configure.in or
configure, just set VERSIONINFO when running configure.

> until I can get this all running under a separate user.

:-) I am preparing some hidden Makefile.am patch ASAP. :)

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 13 Sep 2002 16:55:49 +0000

> configure, just set VERSIONINFO when running configure.

This fictitious variable should be used when running autoconf, not
configure. I wanted to automate this, but retreat for now. autoconf and m4
are really bad tools, they enable to write "Hello, world", but nothing
more. I may implement this for autoconf-2.53, but this is so inconsistent
(in some places you must use ifelse, in some m4_ifelse) and does not work
with older autoconf and requires removing autom4te*.cache every time that
I am disappointed.

BTW, I can now workaround this substr expansion bug by replacing substr
and len with m4_substr and m4_len, but this does not work with 2.13.

So, please for now try to do with configure.in what you suggested above.

Regards,
Mikhael.