On Tue, Feb 25, 2003, Fringe Ryder wrote:
> I was noting the different standards of the environments, not the
> quality of developers.
Nice try, but the fact remains that most of your message was nothing
but an insult against free software developers and that is not the
kind of message you should
> Your example is certainly compelling. I would hope that such initial
> organizations are rare though; I would expect the initial designer who set
> it up that way probably screwed up a lot of other things simultaneously.
Projects change, mature, take on other capabilities, and certainl
At 12:12 PM 2/25/2003 -0500, David A. Desrosiers wrote:
The term "no need to change" isn't a good thing to rely on, however.
Anything can happen in the source code tree, things can move around, get
deleted, pushed into subdirectories, etc. and if you hard-code the relative
path into the so
On Tue, Feb 25, 2003 at 09:22:25AM -0800, Fringe Ryder wrote:
> At 11:32 AM 2/25/2003 -0500, David A. Desrosiers wrote:
> >> Indeed, the Plucker Team has ignored the possibility to build plucker on
> >> Windows.
> >
> >I wouldn't say we've _ignored_ it, just that none of us run
> >
On Tuesday 25 Feb 03, Robert O'Connor writes:
> > Indeed, the Plucker Team has ignored the possibility to build plucker
> > on Windows. Who cares? Despite that oversite, it can be done now,
> > thanks to Cygwin. (That's why Cygwin exists!) Moreover, it's
> > entirely possible that if header-fil
At 11:32 AM 2/25/2003 -0500, David A. Desrosiers wrote:
> Indeed, the Plucker Team has ignored the possibility to build plucker on
> Windows.
I wouldn't say we've _ignored_ it, just that none of us run Windows.
Yeah! When I ran across Plucker back in September, the Plucker team was
very
On Tue, Feb 25, 2003, David Starks-Browning wrote:
> One could ask whether the GCC option "-I/viewer" is
> appropriate.
There are reasons for why some of these options are included; one
reason is to be able to build the viewer in a different directory
than the source code is located in.
/Mike
__
> Indeed, the Plucker Team has ignored the possibility to build plucker
> on Windows. Who cares? Despite that oversite, it can be done now,
> thanks to Cygwin. (That's why Cygwin exists!) Moreover, it's
> entirely possible that if header-file-naming was the only impediment
> to a Cygwin build,
> Your first impression was better; you missed a provided essential detail.
> The solution isn't to hardcode the path, just the relative path of the
> project tree... which has no need to change.
The term "no need to change" isn't a good thing to rely on, however.
Anything can happen in t
On Tuesday 25 Feb 03, Adam McDaniel writes:
> A question about your solution to fix cygwin. Is it possible to
> include a check for that in the configure script? Maybe first check if
> we're using cygwin then check if that environment variable is set.. if
> not print an error.. That would atleast b
At 04:10 PM 2/25/2003 +, Michael Nordström wrote:
On Tue, Feb 25, 2003, Fringe Ryder wrote:
> In such an environment, it would be understood that plucker/viewer
> shouldn't be in the include path. That's a project file; inclusions of it
> would look something like:
> #include "../view
At 10:49 AM 2/25/2003 -0500, David A. Desrosiers wrote:
> It's quite normal to have several inclusions with the same filename but
> different locations in a project, and that's often outside of your control
> completely.
My issue with this, if I understand the problem correctly, is that
it
> Indeed, the Plucker Team has ignored the possibility to build plucker on
> Windows.
I wouldn't say we've _ignored_ it, just that none of us run Windows.
d.
___
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailm
On Tue, Feb 25, 2003 at 04:24:03PM +, David Starks-Browning wrote:
> Indeed, the Plucker Team has ignored the possibility to build plucker
> on Windows. Who cares? Despite that oversite, it can be done now,
> thanks to Cygwin. (That's why Cygwin exists!) Moreover, it's
> entirely possible t
On Tuesday 25 Feb 03, Michael Nordström writes:
> A month from now, you suddenly decide you want to reorganize the file
> structure; while we "lousy" open-source developers only have to change
> a '-I' compiler directive, you "professionals" will go through all your
> source code making these chang
On Tuesday 25 Feb 03, Fringe Ryder writes:
> In such an environment, it would be understood that plucker/viewer
> shouldn't be in the include path. That's a project file; inclusions of it
> would look something like:
> #include "../viewer/font.h"
>
> while core system files are obvious
On Tue, Feb 25, 2003, Fringe Ryder wrote:
> In such an environment, it would be understood that plucker/viewer
> shouldn't be in the include path. That's a project file; inclusions of it
> would look something like:
> #include "../viewer/font.h"
At first, I thought I should be nice and
> Of course Linux/Unix purists will make the claim that a "real" operating
> system (i.e. one with little market share but with case-sensitivity)
At what point was the definition of a "real" operating system
defined by market share? Linux was developed to produce a "free UNIX" for
PCs, no
At 10:23 AM 2/25/2003 +, David Starks-Browning wrote:
On Monday 24 Feb 03, David Starks-Browning writes:
> ...
> Unfortunately, I just found a possible "showstopper" with a Cygwin
> build. Because Windows is case-insensitive with filenames, gcc finds
> plucker/viewer/font.h to satisfy
>
>
On Monday 24 Feb 03, David Starks-Browning writes:
> ...
> Unfortunately, I just found a possible "showstopper" with a Cygwin
> build. Because Windows is case-insensitive with filenames, gcc finds
> plucker/viewer/font.h to satisfy
>
> #include
>
> instead of Core/System/Font.h from the S
20 matches
Mail list logo
