Re: Make CVS HEAD version build out of the box

[Yongwei Wu]

On 30/09/2007, Paul Smith <address@hidden> wrote:
> On Sun, 2007-09-30 at 17:28 +0800, Yongwei Wu wrote:
> > On 30/09/2007, Eli Zaretskii <address@hidden> wrote:
> > > > Date: Sun, 30 Sep 2007 11:20:52 +0800
> > > > From: "Yongwei Wu" <address@hidden>
> > > >
> > > > I found that the CVS HEAD version cannot build out of the box.  Please
> > > > review whether my patch is appropriate.
> > >
> > > Thank you.
> > >
> > > > --- build_w32.bat     4 Jul 2007 19:35:17 -0000       2.13
> > > > +++ build_w32.bat     30 Sep 2007 03:15:30 -0000
> > > > @@ -16,7 +16,7 @@ rem
> > > >  rem You should have received a copy of the GNU General Public License 
> > > > along
> > > >  rem with this program.  If not, see <http://www.gnu.org/licenses/>.
> > > >
> > > > -if not exist config.h copy config.h.W32 config.h
> > > > +if not exist config.h copy config.h.W32.template config.h
> > >
> > > This isn't right: the batch file is for building Make from an official
> > > tarball, not from CVS.
> >
> > I was really guessing my modification might not be right.  However, I
> > do not know how to build Make from CVS, and have not found
> > documentation.
>
> Up until now, as far as I know no one has supported building GNU make
> from CVS on Windows platforms.  To actually create a distribution
> tarball takes a lot of tools such as autoconf, automake, gettext, etc.
> which I believe do run on Windows but are not commonly found.

I have the Cygwin version of these tools installed, but I am not
familiar with them.  So more guidance is needed.

For typical tarballs, I know I can use something like:

CC="gcc -mno-cygwin" ./configure --target=i386-pc-mingw32

In this case, I am not sure how configure should be generated.

> However, I have no objection to the creation of a new batch file or
> whatever that will make this easier.
>
> > > > --- dir.c     4 Jul 2007 19:35:18 -0000       1.66
> > > > +++ dir.c     30 Sep 2007 03:15:31 -0000
> > > > @@ -458,7 +458,7 @@ find_directory (const char *name)
> > > >        /* Remove any trailing '\'.  Windows32 stat fails even on valid
> > > >           directories if they end in '\'. */
> > > >        if (p[-1] == '\\')
> > > > -        p[-1] = '\0';
> > > > +        ((char *)p)[-1] = '\0';
> > > >  #endif
> > > >
> > > >  #ifdef VMS
> > > > @@ -471,7 +471,7 @@ find_directory (const char *name)
> > > >        /* Put back the trailing '\'.  If we don't, we're permanently
> > > >           truncating the value!  */
> > > >        if (p[-1] == '\0')
> > > > -        p[-1] = '\\';
> > > > +        ((char *)p)[-1] = '\\';
> > > >  #endif
> > >
> > > I don't understand why you needed these changes.  Which compiler did
> > > you use, and what error message(s) it emitted, that require such
> > > changes?
> >
> > In the CVS version, "name" and "p" are now declared const char *.  So
> > any decent compiler should complain.  I was using GCC 3.4.5 when
> > compiling.
>
> Well, obviously casting a const char* to a char* so you can modify it is
> not valid code.  There's a reason these values are const, and that
> reason is that they should not be modified.
>
> I can't accept this change; you'll have to find a way of rewriting this
> code that does NOT involve casting away const.

I know it is a hack.  The reason I use this hack is mainly that the
string is restored right away.  Obviously the string-writing code was
done before the paramater is changed from char * to const char *.  The
real-world issue that can happen is multi-threading.  I am not sure
whether Make is multi-threaded.

The other way is to duplicate the string, which may harm the
performance a little bit.  If you believe it is the right way, I can
do it.  That will involve more significant code changes.

Best regards,

Yongwei

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/