Re: bug in configure?
Hello! > > I see that you have committed some fixed to lib/Makefile.am. I have two > > problems with it. If the change is not trivial, please describe it in the > > ChangeLog. > Since I'm a newbie, I've never touched the Changelog (is it a simple > text file or it has a special format?) > Sorry for my ignorance... ChangeLog is just a text file (i.e. there is no program that uses or generates it), but it has a format described in the GNU Coding Standards (run "info standards" to read the description). > > I may reconsider this practice if it gives a bad example to other > > developers. > I've done it without looking at you. Bad practices are very common... Good to know :-) > > I did check the scripts, so it was working for me already. > You are right, they were correct. I've reset the changes by myself... Great! Thank you! > > Feel free to apply those changes if maint/doctest creates empty output > > files (I really should improve it) Improved. -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in configure?
On Tue, Nov 05, 2002 at 12:50:26PM -0500, Pavel Roskin wrote: > Hi, Marco! > > > Sorry for being a newbie and for not being able to find what seems a > > very simple bug indeed. Now for the bug. > > No need to apologize for being a newbie, as long as you don't touch CVS in > the same time :-) Ooops! You've seen me! :-( > > Configure or make should be able to create a valid mc.sh & mc.csh but it > > seems it just copy mc.sh.in & mc.sch.in into mc.sh & mc.csh > > respectively. It seems it does not substitute the @suppbindir@ variable... > > I think you are talking about the CVS version. Then configure doesn't > create mc.sh and mc.csh at all - it's done by make. The reason is because > bindir and suppbindir in configure require further expansion, and I'd > rather do it where it's normally done - in Makefile. I've realized so as you can see... > I see that you have committed some fixed to lib/Makefile.am. I have two > problems with it. If the change is not trivial, please describe it in the > ChangeLog. Since I'm a newbie, I've never touched the Changelog (is it a simple text file or it has a special format?) Sorry for my ignorance... > You can find some of my commits without ChangeLog entries, but they were > made on the same day as the previous change and they were fixing problems > with the previous commit. > Those changes were already described by > ChangeLog. I could add something like "oops, really make it work this > time", but I don't think it would be very useful, especially if the broken > version was on CVS for a few minutes and no snapshot was done from it. > > I may reconsider this practice if it gives a bad example to other > developers. I've done it without looking at you. Bad practices are very common... > The other problem is that you admit being a "newbie" and still apply a > patch without asking anybody. I'd rather see some analysis why the patch > was needed. It wase because of the simplicity of it that I considered it simply a typo... Shame on me!!! I've just discovered that the problem was simply that something was not up to date and the *.in files were not recontructed. Erasing mc/lib entirely and with a cvs checkout solved the problem. > I did check the scripts, so it was working for me already. You are right, they were correct. I've reset the changes by myself... > I'm using Red > Hat 8.0 with GNU make 3.79.1, bash 2.05b and sed 3.02. I don't know what > you were using that it didn't work for you, but it would be very useful if > we all knew that. Mandrake 7.2 GNU Make version 3.79.1 GNU bash, version 2.05.1(1) GNU sed version 3.02 and debian unstable GNU Make version 3.79.1 GNU bash, version 2.05b.0(1) GNU sed version 3.02 . > I would not rely on the fact that configure doesn't substitute > @suppbindir@ - this can easily break in the next version of Automake. I > was consistently using two double quotes after the first @ to prevent > substitution. One benefit of being consistent is that everything breaks > in the same time, like it did for you. This means that the problem is > easier to notice and to fix. Now @bindir@ is escaped by backslashes, and > @suppbindir@ is not escaped. > > I'm very interested to know your versions on make, sed and shell. I want > to see the rule for mc.sh in lib/Makefile you had before applying your > patch. I also want to see the output when mc.sh was generated. > > > And n.2 (just a style matter): I've noted some incoherency in the mc.1 > > man file. Some keys are reported so (for example): > > I think that using .TP and removing all punctuation from the entries would > be the most consistent approach. ok. > Feel free to apply those changes if maint/doctest creates empty output > files (I really should improve it) and you are satisfied how the changed > parts look in the manual (e.g. F3 on mc.1) and in the help (F1). ok. > > -- > Regards, > Pavel Roskin -- La mente e i libri funzionano solo se sono aperti. Sir James Dewar, fisico, (1842-1923) Marco Ciampaicq: 17507004 _ IL TUO SITO DA NUMERO VERDE COME UNA CARTA RICARICABILE! Info al numero verde 800 914 485 http://www.edimedia.com ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in configure?
Hi, Marco! > Sorry for being a newbie and for not being able to find what seems a > very simple bug indeed. Now for the bug. No need to apologize for being a newbie, as long as you don't touch CVS in the same time :-) > Configure or make should be able to create a valid mc.sh & mc.csh but it > seems it just copy mc.sh.in & mc.sch.in into mc.sh & mc.csh > respectively. It seems it does not substitute the @suppbindir@ variable... I think you are talking about the CVS version. Then configure doesn't create mc.sh and mc.csh at all - it's done by make. The reason is because bindir and suppbindir in configure require further expansion, and I'd rather do it where it's normally done - in Makefile. I see that you have committed some fixed to lib/Makefile.am. I have two problems with it. If the change is not trivial, please describe it in the ChangeLog. You can find some of my commits without ChangeLog entries, but they were made on the same day as the previous change and they were fixing problems with the previous commit. Those changes were already described by ChangeLog. I could add something like "oops, really make it work this time", but I don't think it would be very useful, especially if the broken version was on CVS for a few minutes and no snapshot was done from it. I may reconsider this practice if it gives a bad example to other developers. The other problem is that you admit being a "newbie" and still apply a patch without asking anybody. I'd rather see some analysis why the patch was needed. I did check the scripts, so it was working for me already. I'm using Red Hat 8.0 with GNU make 3.79.1, bash 2.05b and sed 3.02. I don't know what you were using that it didn't work for you, but it would be very useful if we all knew that. I would not rely on the fact that configure doesn't substitute @suppbindir@ - this can easily break in the next version of Automake. I was consistently using two double quotes after the first @ to prevent substitution. One benefit of being consistent is that everything breaks in the same time, like it did for you. This means that the problem is easier to notice and to fix. Now @bindir@ is escaped by backslashes, and @suppbindir@ is not escaped. I'm very interested to know your versions on make, sed and shell. I want to see the rule for mc.sh in lib/Makefile you had before applying your patch. I also want to see the output when mc.sh was generated. > And n.2 (just a style matter): I've noted some incoherency in the mc.1 > man file. Some keys are reported so (for example): I think that using .TP and removing all punctuation from the entries would be the most consistent approach. Feel free to apply those changes if maint/doctest creates empty output files (I really should improve it) and you are satisfied how the changed parts look in the manual (e.g. F3 on mc.1) and in the help (F1). -- Regards, Pavel Roskin ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: bug in configure?
On Tue, Nov 05, 2002 at 05:39:12PM +0100, Marco Ciampa wrote: > Sorry for being a newbie and for not being able to find what seems a > very simple bug indeed. > Now for the bug. > > Configure or make should be able to create a valid mc.sh & mc.csh but it > seems it just copy mc.sh.in & mc.sch.in into mc.sh & mc.csh > respectively. It seems it does not substitute the @suppbindir@ variable... > > Is it right? fixed, thanks :-) -- La mente e i libri funzionano solo se sono aperti. Sir James Dewar, fisico, (1842-1923) Marco Ciampaicq: 17507004 _ IL TUO SITO DA NUMERO VERDE COME UNA CARTA RICARICABILE! Info al numero verde 800 914 485 http://www.edimedia.com ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
