* Fixing build bustage under VC++
@ 2002-02-20 20:17 Mo DeJong
2002-02-20 21:13 ` Ian Roxborough
2002-02-20 23:14 ` Ian Roxborough
0 siblings, 2 replies; 7+ messages in thread
From: Mo DeJong @ 2002-02-20 20:17 UTC (permalink / raw)
To: sourcenav
Hi all.
I took a quick look at why sourcenav fails to build under VC++ these days.
The first problem I found showed up when Itcl tried to load tclConfig.sh and
pulled it out of the tcl/unix subdirectory instead of tcl/win. After poking
around for a bit, I found that the following change was to blame for this:
2001-09-12 Ian Roxborough <irox@redhat.com>
* win/configure.in: Set DL_LIBS and MATH_LIBS. Create
unix/tclConfig.sh.
Index: configure.in
===================================================================
RCS file: /cvs/src/src/tcl/win/configure.in,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- configure.in 2001/09/09 23:56:10 1.4
+++ configure.in 2001/09/13 00:38:49 1.5
@@ -230,5 +235,5 @@
AC_SUBST(MAKE_DLL)
AC_SUBST(MAKE_EXE)
-AC_OUTPUT(Makefile tclConfig.sh tcl.hpj)
+AC_OUTPUT(Makefile tclConfig.sh tcl.hpj ../unix/tclConfig.sh)
My question is, why would the tcl/win configure script need to generate
a tclConfig.sh in the ../unix directory? The ChangeLog message seems to
indicate that it has something to do with getting the build working with
the Cygwin compiler. We can't really have two tclConfig.sh scripts like
this because it breaks the m4 macro that searches for either unix/tclConfig.sh
or win/tclConfig.sh.
cheers
Mo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-20 20:17 Fixing build bustage under VC++ Mo DeJong
@ 2002-02-20 21:13 ` Ian Roxborough
2002-02-21 0:08 ` Mo DeJong
2002-02-20 23:14 ` Ian Roxborough
1 sibling, 1 reply; 7+ messages in thread
From: Ian Roxborough @ 2002-02-20 21:13 UTC (permalink / raw)
To: Mo DeJong; +Cc: sourcenav
Mo DeJong wrote:
>
> Hi all.
>
> I took a quick look at why sourcenav fails to build under VC++ these days.
> The first problem I found showed up when Itcl tried to load tclConfig.sh and
> pulled it out of the tcl/unix subdirectory instead of tcl/win. After poking
> around for a bit, I found that the following change was to blame for this:
>
> 2001-09-12 Ian Roxborough <irox@redhat.com>
>
> * win/configure.in: Set DL_LIBS and MATH_LIBS. Create
> unix/tclConfig.sh.
>
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/tcl/win/configure.in,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- configure.in 2001/09/09 23:56:10 1.4
> +++ configure.in 2001/09/13 00:38:49 1.5
> @@ -230,5 +235,5 @@
> AC_SUBST(MAKE_DLL)
> AC_SUBST(MAKE_EXE)
>
> -AC_OUTPUT(Makefile tclConfig.sh tcl.hpj)
> +AC_OUTPUT(Makefile tclConfig.sh tcl.hpj ../unix/tclConfig.sh)
>
> My question is, why would the tcl/win configure script need to generate
> a tclConfig.sh in the ../unix directory? The ChangeLog message seems to
> indicate that it has something to do with getting the build working with
> the Cygwin compiler. We can't really have two tclConfig.sh scripts like
> this because it breaks the m4 macro that searches for either unix/tclConfig.sh
> or win/tclConfig.sh.
This is because some apps need a pure cygwin/UNIX version of Tcl
to work correctly. It was kind of pain to learn that since I'd
already done the upgrade in source.redhat.com and found a dejagnu
and friends wouldn't work....
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-20 21:13 ` Ian Roxborough
@ 2002-02-21 0:08 ` Mo DeJong
2002-02-21 1:23 ` Ian Roxborough
0 siblings, 1 reply; 7+ messages in thread
From: Mo DeJong @ 2002-02-21 0:08 UTC (permalink / raw)
To: sourcenav
On Wed, 20 Feb 2002 21:32:12 -0800
Ian Roxborough <irox@redhat.com> wrote:
...
> > -AC_OUTPUT(Makefile tclConfig.sh tcl.hpj)
> > +AC_OUTPUT(Makefile tclConfig.sh tcl.hpj ../unix/tclConfig.sh)
> >
> > My question is, why would the tcl/win configure script need to generate
> > a tclConfig.sh in the ../unix directory?
...
> This is because some apps need a pure cygwin/UNIX version of Tcl
> to work correctly. It was kind of pain to learn that since I'd
> already done the upgrade in source.redhat.com and found a dejagnu
> and friends wouldn't work....
What does that have to do with the win/ subdir and the VC++ build?
I was under the impression that the tcl/cygwin directory was where
this "pure Cygwin" layer was going to live. I took a peek and
it appears there is a tclConfig.sh.in file in there too, so why would you
want to also create one in the ../unix directory? I think it is just plain
wrong to create a ../unix/tclConfig.sh file from the win subdirectory.
For one thing, the @VAR@ variable names are not always the same.
Also, it breaks the macros that load tclConfig.sh. There must be some
other way to solve the problem, it is just that I don't understand what
the problem was.
Mo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-21 0:08 ` Mo DeJong
@ 2002-02-21 1:23 ` Ian Roxborough
2002-02-21 11:00 ` Mo DeJong
0 siblings, 1 reply; 7+ messages in thread
From: Ian Roxborough @ 2002-02-21 1:23 UTC (permalink / raw)
To: Mo DeJong; +Cc: sourcenav
Mo DeJong wrote:
>
> > This is because some apps need a pure cygwin/UNIX version of Tcl
> > to work correctly. It was kind of pain to learn that since I'd
> > already done the upgrade in source.redhat.com and found a dejagnu
> > and friends wouldn't work....
>
> What does that have to do with the win/ subdir and the VC++ build?
Not really sure.
> I was under the impression that the tcl/cygwin directory was where
> this "pure Cygwin" layer was going to live. I took a peek and
> it appears there is a tclConfig.sh.in file in there too, so why would you
> want to also create one in the ../unix directory? I think it is just plain
> wrong to create a ../unix/tclConfig.sh file from the win subdirectory.
> For one thing, the @VAR@ variable names are not always the same.
> Also, it breaks the macros that load tclConfig.sh. There must be some
> other way to solve the problem, it is just that I don't understand what
> the problem was.
Well, the apps being built think they are being built under UNIX
and look in the ../unix location.
A more correct solution would be to create a ../cygwin/tclConfig.sh
and make all the apps currently using the ../unix/tclConfig.sh
cygwin aware so they know to look in the ../cygwin directory.
The real down side of this is that you've got to make
at least expect (maybe dejagnu and some other Tcl dependent
binutils apps) cygwin aware.
What are your feelings on VC++ vs gcc for building SN?
I'm left with the distinct impression building gcc
would be easier, but then again, I'm just talk about
compiling, I've yet to get it to run.
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-21 1:23 ` Ian Roxborough
@ 2002-02-21 11:00 ` Mo DeJong
2002-02-21 12:06 ` Ian Roxborough
0 siblings, 1 reply; 7+ messages in thread
From: Mo DeJong @ 2002-02-21 11:00 UTC (permalink / raw)
To: sourcenav
On Thu, 21 Feb 2002 01:23:10 -0800
Ian Roxborough <irox@redhat.com> wrote:
...
> > I was under the impression that the tcl/cygwin directory was where
> > this "pure Cygwin" layer was going to live.
...
> Well, the apps being built think they are being built under UNIX
> and look in the ../unix location.
>
> A more correct solution would be to create a ../cygwin/tclConfig.sh
> and make all the apps currently using the ../unix/tclConfig.sh
> cygwin aware so they know to look in the ../cygwin directory.
Well, that should be a simple matter of adding some code to the
CYG_AC_PATH_TCLCONFIG macro defined in src/config/acinclude.m4.
Expect uses this macro so it should be a simple matter of updating
the m4 file and running autoconf in the expect dir. A tcl/cygwin/tclConfig.sh
already exists so that should not be a problem.
> What are your feelings on VC++ vs gcc for building SN?
>
> I'm left with the distinct impression building gcc
> would be easier, but then again, I'm just talk about
> compiling, I've yet to get it to run.
I think we should shoot for getting the VC++ build working again before
working on further gcc support under Windows. The main point of a
SN 5.1 release is to get the bug fixes and Tcl/Tk 8.3 upgrade out to
folks. I don't think that switching the release compiler at the same time
is such a good idea. Last I remember, the VC++ build was working
and SN was running (but, that was many moons ago). I seem to
remember that I had 90% of the packages compiling with mingw, but
there were a couple (perhaps Tix, db, or grep) that were not yet ported.
I know that at least Tcl, Tk, Incr Tcl, and Incr Tk compiled with gcc.
cheers
Mo
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-21 11:00 ` Mo DeJong
@ 2002-02-21 12:06 ` Ian Roxborough
0 siblings, 0 replies; 7+ messages in thread
From: Ian Roxborough @ 2002-02-21 12:06 UTC (permalink / raw)
To: Mo DeJong; +Cc: sourcenav
Mo DeJong wrote:
> > What are your feelings on VC++ vs gcc for building SN?
> >
> > I'm left with the distinct impression building gcc
> > would be easier, but then again, I'm just talk about
> > compiling, I've yet to get it to run.
>
> I think we should shoot for getting the VC++ build working again before
> working on further gcc support under Windows. The main point of a
> SN 5.1 release is to get the bug fixes and Tcl/Tk 8.3 upgrade out to
> folks. I don't think that switching the release compiler at the same time
> is such a good idea. Last I remember, the VC++ build was working
> and SN was running (but, that was many moons ago). I seem to
> remember that I had 90% of the packages compiling with mingw, but
> there were a couple (perhaps Tix, db, or grep) that were not yet ported.
> I know that at least Tcl, Tk, Incr Tcl, and Incr Tk compiled with gcc.
Everything compiles with gcc just now. There is like one
link error in hyper.exe because the tclstubs library is
missing from the link line.
The runtime problems seem to do with a Tcl_Preserve call
setting the interp pointer to NULL, but I've not tracked
down why. I think I've seen similar problems with the
gcc compiled wish83, however some thing about Insight's Init
code let's it avoid this problem.
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fixing build bustage under VC++
2002-02-20 20:17 Fixing build bustage under VC++ Mo DeJong
2002-02-20 21:13 ` Ian Roxborough
@ 2002-02-20 23:14 ` Ian Roxborough
1 sibling, 0 replies; 7+ messages in thread
From: Ian Roxborough @ 2002-02-20 23:14 UTC (permalink / raw)
To: Mo DeJong; +Cc: sourcenav
Mo DeJong wrote:
>
> Hi all.
>
> I took a quick look at why sourcenav fails to build under VC++ these days.
Cool.
I built Source-Navigator with gcc/cygwin today,
there wheren't too many changes to do, I was pretty
impressed that it built, how ever it didn't run
and I didn't have time to look why it was crashing
on start up.
I'd prefer to make gcc the default compiler for
Windows, because VC++ costs money and it'll be
easier to support since it's closer to the UNIX
version.
I've going to look into it again, maybe it's not
going to take too much to fix.
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-02-21 19:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-20 20:17 Fixing build bustage under VC++ Mo DeJong
2002-02-20 21:13 ` Ian Roxborough
2002-02-21 0:08 ` Mo DeJong
2002-02-21 1:23 ` Ian Roxborough
2002-02-21 11:00 ` Mo DeJong
2002-02-21 12:06 ` Ian Roxborough
2002-02-20 23:14 ` Ian Roxborough
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).