Can we add http://troi.lincom-asg.com/~rjamison/inkscape/builds/ to the "download.php" list of CVS snapshots?
(btw: did the 2004-05-09 autobuild under windows blow up?)
On Mon, 10 May 2004, Kees Cook wrote:
Can we add http://troi.lincom-asg.com/~rjamison/inkscape/builds/ to the "download.php" list of CVS snapshots?
(btw: did the 2004-05-09 autobuild under windows blow up?)
It probably failed, but it should be fixed now.
Carl
Kees Cook wrote:
Can we add http://troi.lincom-asg.com/~rjamison/inkscape/builds/ to the "download.php" list of CVS snapshots?
Well, keep in mind that these are not "official", but are just a convenience for Win32 testers. I really don't see this as a permanent resource, but it works for now. I think that eventually the nightly builds will need to be adopted by some other kind altruistic soul.
By the way, "lincom-asg.com" will disappear next week. The company was merged with Titan 3 years ago, so the domain name really has been in limbo for this time. The new domain should work though:
http://troi.titan-aeu.com/~rjamison/inkscape/builds/
(btw: did the 2004-05-09 autobuild under windows blow up?)
Sometimes they work, sometimes they don't. :-) Usually it is a sync problem between Win32 Makedep and Linux Makefile.am's. Or maybe someone committed code that works fine on Linux, but not on Mingw. prefix.cpp was a good example of code that needed a bit of tweaking to be portable.
I really should add a dependency to src/Makefile.mingw, so that a change to src/Makefile.am will cause a Win32 Makedep to be run automatically. On the other hand, I don't want to require Win32 builders to download and install Perl.
Bob (Ishmal)
On Mon, May 10, 2004 at 02:18:04PM -0500, Bob Jamison wrote:
Well, keep in mind that these are not "official", but are just a convenience for Win32 testers. I really don't see this as a permanent resource, but it works for now. I think that eventually the nightly builds will need to be adopted by some other kind altruistic soul.
Well, that's my goal... anyone grabbing CVS snapshots is basically a tester. :) That's where I wanted to list it.
Noted.
On Mon, May 10, 2004 at 02:18:04PM -0500, Bob Jamison wrote:
This doesn't resolve, actually...
On Mon, May 10, 2004 at 02:18:04PM -0500, Bob Jamison wrote:
Sometimes they work, sometimes they don't. :-) Usually it is a sync problem between Win32 Makedep and Linux Makefile.am's. Or maybe someone committed code that works fine on Linux, but not on Mingw. prefix.cpp was a good example of code that needed a bit of tweaking to be portable.
I really should add a dependency to src/Makefile.mingw, so that a change to src/Makefile.am will cause a Win32 Makedep to be run automatically. On the other hand, I don't want to require Win32 builders to download and install Perl.
Can someone verify that the windows build is correctly updating "config.h": the g_ascii_strtod macro isn't being defined in the autobuilds, it looks like.
On Wed, 12 May 2004, Kees Cook wrote:
On Mon, May 10, 2004 at 02:18:04PM -0500, Bob Jamison wrote:
Sometimes they work, sometimes they don't. :-) Usually it is a sync problem between Win32 Makedep and Linux Makefile.am's. Or maybe someone committed code that works fine on Linux, but not on Mingw. prefix.cpp was a good example of code that needed a bit of tweaking to be portable.
I really should add a dependency to src/Makefile.mingw, so that a change to src/Makefile.am will cause a Win32 Makedep to be run automatically. On the other hand, I don't want to require Win32 builders to download and install Perl.
Can someone verify that the windows build is correctly updating "config.h": the g_ascii_strtod macro isn't being defined in the autobuilds, it looks like.
AFAIK the windows build uses inkscape/config.h.mingw as its config.h. Anything that needs to be in config.h must be added here, I think.
Carl
On Wed, May 12, 2004 at 04:18:40PM +0100, Carl Hetherington wrote:
AFAIK the windows build uses inkscape/config.h.mingw as its config.h. Anything that needs to be in config.h must be added here, I think.
Manually added? It doesn't get auto-built like the normal config.h?
On Wed, 12 May 2004, Kees Cook wrote:
On Wed, May 12, 2004 at 04:18:40PM +0100, Carl Hetherington wrote:
AFAIK the windows build uses inkscape/config.h.mingw as its config.h. Anything that needs to be in config.h must be added here, I think.
Manually added? It doesn't get auto-built like the normal config.h?
1. Yes; 2. No. ;-)
Rather than suffer the PITA of getting autoconf to work in Windows we just assume that all Windows are equal...
Carl
Kees Cook wrote:
On Wed, May 12, 2004 at 04:18:40PM +0100, Carl Hetherington wrote:
AFAIK the windows build uses inkscape/config.h.mingw as its config.h. Anything that needs to be in config.h must be added here, I think.
Manually added? It doesn't get auto-built like the normal config.h?
Correct. The average poor M$ Windows victim does not have automake/autoconf available.
Bob
Bob Jamison wrote:
Correct. The average poor M$ Windows victim does not have automake/autoconf available.
Well, that sounded curt and smug. :-) .
Let me explain this better. IS/SP has always been buildable on Win32. The problem with the SP build, though, was that the Win32 builder had to download and configure a lot of things to make it to work. Mingw, MSYS, automake, autoconf, pkg-config, the codepages, etc. He would spend more time on THAT than the actual code.
What a pain for the average developer/user who merely wants to make Inkscape do what he wants it to do. Why waste days and days getting it to compile, when the developer would rather be working on the program itself?
So we spent several weeks collecting libraries, building others, installing the codepages into the source (which we can delete soon because of Pango) and creating a set of clean makefiles that work on Win9x, NT, XP, and the Linux cross-compiler. It is a bit more work for people like me, but hopefully it attains its goal of saving a lot of work for other people.
Also, remember that on Unix/Linux, $PREFIX is commonly /usr/local or /usr or something like that. On M$, all of a program's files are typically located in their own directory. So all of the files are located relative to ".". Actually, relative to the .exe that is currently running.
.....anyway, just wanted to explain that there is a reason for the Win32 build to be constructed in such a manner, and that we haven't just been arbitrary.
hth
I will check with the admin to see why the name server does not have the new address yet.
Bob (ishmal)
On Thu, May 13, 2004 at 02:24:31AM -0500, Bob Jamison wrote:
.....anyway, just wanted to explain that there is a reason for the Win32 build to be constructed in such a manner, and that we haven't just been arbitrary.
Yup! That all makes sense. I just didn't realize the process. Maybe we should put a note in configure.in that mentions the need to add AC_DEFINE'd stuff to config.h.mingw?
I've added this to the Wiki page on CreatingDists.
http://www.inkscape.org/cgi-bin/wiki.pl?CreatingDists
Bryce
On Thu, 13 May 2004, Bob Jamison wrote:
Bob Jamison wrote:
Correct. The average poor M$ Windows victim does not have automake/autoconf available.
Well, that sounded curt and smug. :-) .
Let me explain this better. IS/SP has always been buildable on Win32. The problem with the SP build, though, was that the Win32 builder had to download and configure a lot of things to make it to work. Mingw, MSYS, automake, autoconf, pkg-config, the codepages, etc. He would spend more time on THAT than the actual code.
What a pain for the average developer/user who merely wants to make Inkscape do what he wants it to do. Why waste days and days getting it to compile, when the developer would rather be working on the program itself?
So we spent several weeks collecting libraries, building others, installing the codepages into the source (which we can delete soon because of Pango) and creating a set of clean makefiles that work on Win9x, NT, XP, and the Linux cross-compiler. It is a bit more work for people like me, but hopefully it attains its goal of saving a lot of work for other people.
Also, remember that on Unix/Linux, $PREFIX is commonly /usr/local or /usr or something like that. On M$, all of a program's files are typically located in their own directory. So all of the files are located relative to ".". Actually, relative to the .exe that is currently running.
.....anyway, just wanted to explain that there is a reason for the Win32 build to be constructed in such a manner, and that we haven't just been arbitrary.
hth
I will check with the admin to see why the name server does not have the new address yet.
Bob (ishmal)
This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
Bob Jamison -
Bryce Harrington -
Carl Hetherington -
Kees Cook