www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Current RDMD, please?

reply "Nick Sabalausky" <a a.a> writes:
The RDMD included with DMD is still 20090902, which is two revisions 
out-of-date.

The lack of the fix in r1315 ("Made relative paths searched from the main 
file, not the current dir") is a breaker for using RDMD with my projects, 
which is particularly bad since xfbuild (my other go-to build tool) seems to 
have become incompatible with newer D2s (Ie, certain basic things that work 
with newer DMDs get choked on by xfbuild). I know I can compile the latest 
RDMD myself, but anyone else compiling my stuff (or using my stbuild tool) 
has to do the same.

So can we please get the current RDMD included with the next DMD 
(particularly D2) release?

This has been brought up at least a couple times before, and didn't get any 
official response. Is there something preventing this from happening that 
maybe I could help out on?
Aug 16 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 which is particularly bad since xfbuild (my other go-to build tool) seems to 
 have become incompatible with newer D2s (Ie, certain basic things that work 
 with newer DMDs get choked on by xfbuild).


If/once xfbuild shows to be good enough and easy enough to use (I have never
used it so far), it may be added to the standard dmd distribution.

Bye,
bearophile
Aug 16 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 The RDMD included with DMD is still 20090902, which is two revisions 
 out-of-date.
 
 The lack of the fix in r1315 ("Made relative paths searched from the main 
 file, not the current dir") is a breaker for using RDMD with my projects, 
 which is particularly bad since xfbuild (my other go-to build tool) seems to 
 have become incompatible with newer D2s (Ie, certain basic things that work 
 with newer DMDs get choked on by xfbuild). I know I can compile the latest 
 RDMD myself, but anyone else compiling my stuff (or using my stbuild tool) 
 has to do the same.
 
 So can we please get the current RDMD included with the next DMD 
 (particularly D2) release?
 
 This has been brought up at least a couple times before, and didn't get any 
 official response. Is there something preventing this from happening that 
 maybe I could help out on? 


Walter, could you please update your build scripts to build and include 
rdmd? It's an important tool. Thanks.

Andrei
Aug 16 2010
next sibling parent Nick Sabalausky <aaaaaa aaaaaaa.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 Walter, could you please update your build scripts to build and include
 rdmd? It's an important tool. Thanks.
 Andrei


That would be great...

But it seems rdmd and my project still aren't getting along (the change in r1315
*does* help though, just not 100%). I'd like to investigate this further and
maybe
provide a patch, but I have some questions about it:

Let me start by outlining [a simplified version of] my project's setup:

My package system is something like this:
module myproj.apps.appA.main; // AppA's 'void main()'
module myproj.apps.appB.main; // AppB's 'void main()'
module myproj.lib.foo; // Foo module, common to both apps

All of the source lives in a "src" subdirectory directly off my project's main
directory. Ie, the modules above correspond to:

{main proj dir}/src/myproj/apps/appA/main.d
{main proj dir}/src/myproj/apps/appB/main.d
{main proj dir}/src/myproj/lib/foo.d

Then there's a build script directly in "{main proj dir}" that tries to build
AppA
by calling:

rdmd -ofbin/appA -Isrc --build-only src/myproj/apps/appA/main.d

Before r1315 (ie the rdmd currently packaged with dmd), rdmd would cd into
"src/myproj/apps/appA/" and would, of course, be unable to find
"src/myproj/apps/appA/main.d" from there.

After r1315 (actually, I'm using the one from r1400), rdmd accessess
"src/myproj/apps/appA/main.d" and gets the deps just fine, since it doesn't cd
anywhere. But then it'll prepend "src/myproj/apps/appA/" to the non-phobos
dependencies and end up telling dmd to compile
"src/myproj/apps/appA/src/myproj/lib/foo.d", which, of course, is a butchered
path.



myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;

to:

myModules[moduleSrc] = moduleObj;

With that change, all is well for me.

So, I would file a ticket with that one-line patch, but I'm not sure if there
was
a specific reason that rootDir should be prepended. Ie, is there some use-case
that would break? If not, then I'll just file that as a ticket, and hopefully it
can be included in the next release. But if not, could you explain what I'm
overlooking so I can try to come up with a patch that would be appropriate?
Aug 16 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i4cq4p$7jv$3 digitalmars.com...

 Nick Sabalausky wrote:

 The RDMD included with DMD is still 20090902, which is two revisions 
 out-of-date.

 The lack of the fix in r1315 ("Made relative paths searched from the main 
 file, not the current dir") is a breaker for using RDMD with my projects, 
 which is particularly bad since xfbuild (my other go-to build tool) seems 
 to have become incompatible with newer D2s (Ie, certain basic things that 
 work with newer DMDs get choked on by xfbuild). I know I can compile the 
 latest RDMD myself, but anyone else compiling my stuff (or using my 
 stbuild tool) has to do the same.

 So can we please get the current RDMD included with the next DMD 
 (particularly D2) release?

 This has been brought up at least a couple times before, and didn't get 
 any official response. Is there something preventing this from happening 
 that maybe I could help out on?


 Walter, could you please update your build scripts to build and include 
 rdmd? It's an important tool. Thanks.


My last post was overly long-winded. Summay:



    myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;

instead of:

    myModules[moduleSrc] = moduleObj;

...? (ie, rdmd prepends "path to the file with main()" to all of the 
relative paths in the deps file)

The former causes problems for me, but when I change it to the latter all is 
fine for me.
Aug 17 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/17/2010 01:34 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i4cq4p$7jv$3 digitalmars.com...

 Nick Sabalausky wrote:

 The RDMD included with DMD is still 20090902, which is two revisions
 out-of-date.

 The lack of the fix in r1315 ("Made relative paths searched from the main
 file, not the current dir") is a breaker for using RDMD with my projects,
 which is particularly bad since xfbuild (my other go-to build tool) seems
 to have become incompatible with newer D2s (Ie, certain basic things that
 work with newer DMDs get choked on by xfbuild). I know I can compile the
 latest RDMD myself, but anyone else compiling my stuff (or using my
 stbuild tool) has to do the same.

 So can we please get the current RDMD included with the next DMD
 (particularly D2) release?

 This has been brought up at least a couple times before, and didn't get
 any official response. Is there something preventing this from happening
 that maybe I could help out on?


 Walter, could you please update your build scripts to build and include
 rdmd? It's an important tool. Thanks.


 My last post was overly long-winded. Summay:



      myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;

 instead of:

      myModules[moduleSrc] = moduleObj;

 ...? (ie, rdmd prepends "path to the file with main()" to all of the
 relative paths in the deps file)

 The former causes problems for me, but when I change it to the latter all is
 fine for me.


I saw the q, and was still mulling for an answer. I the join 
intentionally, and now I think I remembered why.

The join is needed in the probably rare case when you're running rdmd 
from a different directory from the root module, e.g:

$ pwd
~/foo/bar
$ rdmd ../baz/main.d

In this case, if there's no join with the rootDir, modules will be 
looked up in ~/foo/bar/, which is probably not the right thing.

What is your use case?


Andrei
Aug 17 2010
next sibling parent reply simendsjo <simen.endsjo pandavre.com> writes:
On 17.08.2010 21:08, Andrei Alexandrescu wrote:

 On 08/17/2010 01:34 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:i4cq4p$7jv$3 digitalmars.com...

 Nick Sabalausky wrote:

 The RDMD included with DMD is still 20090902, which is two revisions
 out-of-date.

 The lack of the fix in r1315 ("Made relative paths searched from the
 main
 file, not the current dir") is a breaker for using RDMD with my
 projects,
 which is particularly bad since xfbuild (my other go-to build tool)
 seems
 to have become incompatible with newer D2s (Ie, certain basic things
 that
 work with newer DMDs get choked on by xfbuild). I know I can compile
 the
 latest RDMD myself, but anyone else compiling my stuff (or using my
 stbuild tool) has to do the same.

 So can we please get the current RDMD included with the next DMD
 (particularly D2) release?

 This has been brought up at least a couple times before, and didn't get
 any official response. Is there something preventing this from
 happening
 that maybe I could help out on?


 Walter, could you please update your build scripts to build and include
 rdmd? It's an important tool. Thanks.


 My last post was overly long-winded. Summay:



 myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;

 instead of:

 myModules[moduleSrc] = moduleObj;

 ...? (ie, rdmd prepends "path to the file with main()" to all of the
 relative paths in the deps file)

 The former causes problems for me, but when I change it to the latter
 all is
 fine for me.


 I saw the q, and was still mulling for an answer. I the join
 intentionally, and now I think I remembered why.

 The join is needed in the probably rare case when you're running rdmd
 from a different directory from the root module, e.g:

 $ pwd
 ~/foo/bar
 $ rdmd ../baz/main.d

 In this case, if there's no join with the rootDir, modules will be
 looked up in ~/foo/bar/, which is probably not the right thing.

 What is your use case?


 Andrei


But I don't think that works. This is a copy of a post I made in d.learn 
the other day:

c:\temp\src\test.d

c:\temp>rdmd src\test
The system cannot find the path specified.

c:\temp>rdmd src/test
std.file.FileException: (...)\.rdmd\rdmd-src/test.d-(...): The system 
cannot find the path specified.

Using rdmd 20090902, dmd 2.048 and 64 bit win7
Aug 17 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/17/2010 03:06 PM, simendsjo wrote:

 On 17.08.2010 21:08, Andrei Alexandrescu wrote:

 On 08/17/2010 01:34 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org> wrote in message
 news:i4cq4p$7jv$3 digitalmars.com...

 Nick Sabalausky wrote:

 The RDMD included with DMD is still 20090902, which is two revisions
 out-of-date.

 The lack of the fix in r1315 ("Made relative paths searched from the
 main
 file, not the current dir") is a breaker for using RDMD with my
 projects,
 which is particularly bad since xfbuild (my other go-to build tool)
 seems
 to have become incompatible with newer D2s (Ie, certain basic things
 that
 work with newer DMDs get choked on by xfbuild). I know I can compile
 the
 latest RDMD myself, but anyone else compiling my stuff (or using my
 stbuild tool) has to do the same.

 So can we please get the current RDMD included with the next DMD
 (particularly D2) release?

 This has been brought up at least a couple times before, and didn't
 get
 any official response. Is there something preventing this from
 happening
 that maybe I could help out on?


 Walter, could you please update your build scripts to build and include
 rdmd? It's an important tool. Thanks.


 My last post was overly long-winded. Summay:



 myModules[/*rel2abs*/join(rootDir, moduleSrc)] = moduleObj;

 instead of:

 myModules[moduleSrc] = moduleObj;

 ...? (ie, rdmd prepends "path to the file with main()" to all of the
 relative paths in the deps file)

 The former causes problems for me, but when I change it to the latter
 all is
 fine for me.


 I saw the q, and was still mulling for an answer. I the join
 intentionally, and now I think I remembered why.

 The join is needed in the probably rare case when you're running rdmd
 from a different directory from the root module, e.g:

 $ pwd
 ~/foo/bar
 $ rdmd ../baz/main.d

 In this case, if there's no join with the rootDir, modules will be
 looked up in ~/foo/bar/, which is probably not the right thing.

 What is your use case?


 Andrei


 But I don't think that works. This is a copy of a post I made in d.learn
 the other day:

 c:\temp\src\test.d

 c:\temp>rdmd src\test
 The system cannot find the path specified.

 c:\temp>rdmd src/test
 std.file.FileException: (...)\.rdmd\rdmd-src/test.d-(...): The system
 cannot find the path specified.

 Using rdmd 20090902, dmd 2.048 and 64 bit win7


Works for me on Ubuntu, though I have 20091008. Looks like a 
Windows-specific matter. The second error message suggests that the 
temporary directory chosen by rdmd is not working properly.

Andrei
Aug 17 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"simendsjo" <simen.endsjo pandavre.com> wrote in message 
news:i4eq4l$o69$1 digitalmars.com...

 On 17.08.2010 21:08, Andrei Alexandrescu wrote:

 But I don't think that works. This is a copy of a post I made in d.learn 
 the other day:

 c:\temp\src\test.d

 c:\temp>rdmd src\test
 The system cannot find the path specified.

 c:\temp>rdmd src/test
 std.file.FileException: (...)\.rdmd\rdmd-src/test.d-(...): The system 
 cannot find the path specified.

 Using rdmd 20090902, dmd 2.048 and 64 bit win7


That's an old bug that's fixed in the rdmd trunk (it was fixed in r1315). 
That's the original reason I wanted an updated rdmd to get included.

The problem in that old version of rdmd is that it always cd's into the 
directory with the main d file. So it basically does this:

c:\temp\src\test.d

c:\temp>rdmd src\test
[rdmd]> cd src
[rdmd]> dmd src\test.d

So it didn't work from any directory other than the one with the main d 
file. But that was already fixed in trunk last year (and just never got 
included into the DMD distrubutions yet).
Aug 17 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i4emnt$bcs$1 digitalmars.com...

 I saw the q, and was still mulling for an answer. I the join 
 intentionally, and now I think I remembered why.

 The join is needed in the probably rare case when you're running rdmd from 
 a different directory from the root module, e.g:

 $ pwd
 ~/foo/bar
 $ rdmd ../baz/main.d

 In this case, if there's no join with the rootDir, modules will be looked 
 up in ~/foo/bar/, which is probably not the right thing.

 What is your use case?


That's what I was starting to suspect.

My case (writing this from memory, if this doesn't behave like I describe, 
then it's something along these lines):

$ cat src/app/main.d
module app.main;
import foo;
void main(){}

$ cat src/lib/foo.d
module lib.foo;

$ xfbuild -Isrc src/app/main.d
Works ok

$ rdmd -Isrc src/app/main.d
dmd craps out because rdmd told it to compile "src/app/src/lib/foo.d"
Aug 17 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i4et66$141a$1 digitalmars.com...

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:i4emnt$bcs$1 digitalmars.com...

 I saw the q, and was still mulling for an answer. I the join 
 intentionally, and now I think I remembered why.

 The join is needed in the probably rare case when you're running rdmd 
 from a different directory from the root module, e.g:

 $ pwd
 ~/foo/bar
 $ rdmd ../baz/main.d

 In this case, if there's no join with the rootDir, modules will be looked 
 up in ~/foo/bar/, which is probably not the right thing.

 What is your use case?


 That's what I was starting to suspect.

 My case (writing this from memory, if this doesn't behave like I describe, 
 then it's something along these lines):

 $ cat src/app/main.d
 module app.main;
 import foo;
 void main(){}

 $ cat src/lib/foo.d
 module lib.foo;

 $ xfbuild -Isrc src/app/main.d
 Works ok

 $ rdmd -Isrc src/app/main.d
 dmd craps out because rdmd told it to compile "src/app/src/lib/foo.d"


Maybe if you just implicitly add "-I{rootDir}" to the args sent to dmd 
instead of prepending rootDir? Ideally, you would also want to tell DMD to 
*not* to lookup modules in the current directory (unless rootDir == current 
directory), although I don't think DMD has an option for that right now.
Aug 17 2010
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i4ev6m$1bpl$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:i4et66$141a$1 digitalmars.com...

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:i4emnt$bcs$1 digitalmars.com...

 I saw the q, and was still mulling for an answer. I the join 
 intentionally, and now I think I remembered why.

 The join is needed in the probably rare case when you're running rdmd 
 from a different directory from the root module, e.g:

 $ pwd
 ~/foo/bar
 $ rdmd ../baz/main.d

 In this case, if there's no join with the rootDir, modules will be 
 looked up in ~/foo/bar/, which is probably not the right thing.

 What is your use case?


 That's what I was starting to suspect.

 My case (writing this from memory, if this doesn't behave like I 
 describe, then it's something along these lines):

 $ cat src/app/main.d
 module app.main;
 import foo;
 void main(){}

 $ cat src/lib/foo.d
 module lib.foo;

 $ xfbuild -Isrc src/app/main.d
 Works ok

 $ rdmd -Isrc src/app/main.d
 dmd craps out because rdmd told it to compile "src/app/src/lib/foo.d"


 Maybe if you just implicitly add "-I{rootDir}" to the args sent to dmd 
 instead of prepending rootDir? Ideally, you would also want to tell DMD to 
 *not* to lookup modules in the current directory (unless rootDir == 
 current directory), although I don't think DMD has an option for that 
 right now.


I've submitted a modified rdmd.d that does exactly that:

http://d.puremagic.com/issues/show_bug.cgi?id=4672

I've verified that this works for both my use-case (ie, when "-I" is needed) 
AND for your example (ie, making sure that modules which are relative to the 
main file are looked up correctly regardless of what directory rdmd is run 
from).
Aug 18 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 This has been brought up at least a couple times before, and didn't get any 
 official response. Is there something preventing this from happening that 
 maybe I could help out on? 


I'll take care of it. Sorry about the delays.
Aug 16 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-17 08:29, Walter Bright wrote:

 Nick Sabalausky wrote:

 This has been brought up at least a couple times before, and didn't
 get any official response. Is there something preventing this from
 happening that maybe I could help out on?


 I'll take care of it. Sorry about the delays.


Please build the Mac version on Mac OS X 10.5 if possible otherwise it 
will only run on Mac OS X 10.6. This should really be fixed in possible.

-- 
/Jacob Carlborg
Aug 17 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:

 Please build the Mac version on Mac OS X 10.5 if possible otherwise it 
 will only run on Mac OS X 10.6. This should really be fixed in possible.


10.6 is over a year old, why not upgrade?
Aug 17 2010
next sibling parent reply lurker <lurkers lurking.org> writes:
Walter Bright Wrote:


 Jacob Carlborg wrote:

 Please build the Mac version on Mac OS X 10.5 if possible otherwise it 
 will only run on Mac OS X 10.6. This should really be fixed in possible.


 
 10.6 is over a year old, why not upgrade?


It costs money - money doesn't grow on trees?
Aug 17 2010
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
But he's a Mac user! :p

On Tue, Aug 17, 2010 at 7:35 PM, lurker <lurkers lurking.org> wrote:


 Walter Bright Wrote:


 Jacob Carlborg wrote:

 Please build the Mac version on Mac OS X 10.5 if possible otherwise it
 will only run on Mac OS X 10.6. This should really be fixed in




 possible.

 10.6 is over a year old, why not upgrade?


 It costs money - money doesn't grow on trees?
Aug 17 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.343.1282068838.13841.digitalmars-d puremagic.com...

 But he's a Mac user! :p


Heh, that was exactly my thought ;)  I'm not a mac user (nearly-immediate 
obsolescence is one of the reasons I left the Mac world after giving OSX a 
serious try for a couple years). My primary OS is ten years old (unless you 
count service packs), and I'm perfectly happy with it (well, much more happy 
than I would be with the newer versions of it, like Win7 - I swear, MS's 
devs are getting to be like Mozilla's).
Aug 17 2010
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well, I didn't really mean anything by it. :)

AFAIK the update from 10.5 to 10.6 wasn't all that expensive? Wasn't this
the Leopard > Snow Leopard patch?

OT: I like OSX, everything is very consistent and in place. But I've
overcustomized my system so much that switching to anything else would be a
pain.

On Tue, Aug 17, 2010 at 8:45 PM, Nick Sabalausky <a a.a> wrote:


 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.343.1282068838.13841.digitalmars-d puremagic.com...

 But he's a Mac user! :p


 Heh, that was exactly my thought ;)  I'm not a mac user (nearly-immediate
 obsolescence is one of the reasons I left the Mac world after giving OSX a
 serious try for a couple years). My primary OS is ten years old (unless you
 count service packs), and I'm perfectly happy with it (well, much more
 happy
 than I would be with the newer versions of it, like Win7 - I swear, MS's
 devs are getting to be like Mozilla's).
Aug 17 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:

 But I've 
 overcustomized my system so much that switching to anything else would 
 be a pain.


To Apple's credit, the upgrade from OS X 10.5 to 10.6 was the least painful of 
any upgrade I've done, from Windows to Linux, because it is the only one where
I 
did not have to resort to reformatting the disk and reinstalling everything. 
Microsoft's migration tools, even for their own software, never ever worked. 
Neither did Ubuntu's.

I'm still running XP because I don't want to spend 2 or 3 days finding the 
install disks for my programs and reinstalling everything.

On the other hand, the configuration screen for the installer had buttons down 
at the bottom of the screen, and my display was smaller than the standard Apple 
one, and so the buttons were off screen. This caused considerable misery before 
I figured out why there were no continue buttons.
Aug 17 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
 news:mailman.343.1282068838.13841.digitalmars-d puremagic.com...

 But he's a Mac user! :p


 
 Heh, that was exactly my thought ;)  I'm not a mac user (nearly-immediate 
 obsolescence is one of the reasons I left the Mac world after giving OSX a 
 serious try for a couple years). My primary OS is ten years old (unless you 
 count service packs), and I'm perfectly happy with it (well, much more happy 
 than I would be with the newer versions of it, like Win7 - I swear, MS's 
 devs are getting to be like Mozilla's). 


I'm using a 10 year old Windows XP version, but the difference between the Mac 
world and the Windows world is Microsoft cares about legacy compatibility, and 
my experience with Mac OS X 10.4 .. 10.6 is that Apple goes out of their way to 
make it difficult to build backwards compatible binaries.

Take a look at the dmd makefiles for OS X. Worse, Apple's documentation on how 
to do this is contradictory and spread out over obscure web pages, so there's a 
fair amount of trial and error to get it set up right. (If Apple cared about 
this, there'd be nothing more than a switch to g++ along the lines of -osx=10.4 
and it'll do whatever is necessary to build a backward compatible binary.)

On the other hand, OS X upgrades tend to be cheap ($25) while Windows upgrades 
tend to be expensive (hundreds of $).
Aug 17 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:i4en9n$dpu$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
 news:mailman.343.1282068838.13841.digitalmars-d puremagic.com...

 But he's a Mac user! :p


 Heh, that was exactly my thought ;)  I'm not a mac user (nearly-immediate 
 obsolescence is one of the reasons I left the Mac world after giving OSX 
 a serious try for a couple years). My primary OS is ten years old (unless 
 you count service packs), and I'm perfectly happy with it (well, much 
 more happy than I would be with the newer versions of it, like Win7 - I 
 swear, MS's devs are getting to be like Mozilla's).


 I'm using a 10 year old Windows XP version, but the difference between the 
 Mac world and the Windows world is Microsoft cares about legacy 
 compatibility, and my experience with Mac OS X 10.4 .. 10.6 is that Apple 
 goes out of their way to make it difficult to build backwards compatible 
 binaries.


I got into OSX with 10.1 and 10.2, and my sister had 10.3, and my exprience 
indecates that Apple's outright disdain for anything that isn't *the most 
recect* go back much furthur than just 10.4.


 On the other hand, OS X upgrades tend to be cheap ($25) while Windows 
 upgrades tend to be expensive (hundreds of $).


That's news to me. Going from 10.1 to 10.2 was $125 (despite the fact that 
there was *very* little change as far as I could tell). Same thing for 10.2 
to 10.3. And of course, if you've gone from 10.3 (maybe even 10.4) to 10.6, 
then at some point along the way you have to buy new hardware, and it's not 
nearly as cheap as the machines Windows runs on. My Windows machine is older 
than 10.2 and Win7 would run on it just fine (even better than XP, from what 
I've heard).

I seem to recall seeing a lot of Windows upgrades that were only around a 
hundered or so, too. AIUI, the Windows upgrades that cost hundreds (plural) 
are generally the bigger ones, like XP Home to Vista Pro, or 
corporate-oriented edition to corporate-oriented edition.

Plus, Windows has a lot of free service packs. From what I've been able to 
tell, OSX just gives their service packs a new cat's name, tosses in a 
couple of gee-whiz gimmicks, and charges $125.
Aug 17 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i4er4n$ski$1 digitalmars.com...

 I got into OSX with 10.1 and 10.2, and my sister had 10.3,


(She also got fed up with Apple's, well, what's essentially a 
subscription-model, and has since switched to Win7.)
Aug 17 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-17 16:24:01 -0400, "Nick Sabalausky" <a a.a> said:


 "Walter Bright" <newshound2 digitalmars.com> wrote in message
 news:i4en9n$dpu$1 digitalmars.com...

 On the other hand, OS X upgrades tend to be cheap ($25) while Windows
 upgrades tend to be expensive (hundreds of $).


 
 That's news to me.


Snow Leopard is priced much lower than the usual OS X upgrade. Apple 
can't charge too much for just adding some snow on a leopard. :-)

10.6's price might be the exception to the rule, or it might be the new 
rule. We'll have to wait until the next upgrade to know.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Aug 17 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:

 10.6's price might be the exception to the rule, or it might be the new 
 rule. We'll have to wait until the next upgrade to know.


It's my only experience with OS X upgrades.
Aug 19 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:

 I got into OSX with 10.1 and 10.2, and my sister had 10.3, and my exprience 
 indecates that Apple's outright disdain for anything that isn't *the most 
 recect* go back much furthur than just 10.4.


I suspected that, but I thought I'd stick with what I knew for sure.



 Plus, Windows has a lot of free service packs.


Yeah, I like those. Those have never required a reformat of my hard disk. But 
the major OS revisions always have, despite MS's "migration tools".
Aug 19 2010
parent reply retard <re tard.com.invalid> writes:
Thu, 19 Aug 2010 13:13:20 -0700, Walter Bright wrote:


 Nick Sabalausky wrote:

 I got into OSX with 10.1 and 10.2, and my sister had 10.3, and my
 exprience indecates that Apple's outright disdain for anything that
 isn't *the most recect* go back much furthur than just 10.4.


 
 I suspected that, but I thought I'd stick with what I knew for sure.
 
 

 Plus, Windows has a lot of free service packs.


 
 Yeah, I like those. Those have never required a reformat of my hard
 disk. But the major OS revisions always have, despite MS's "migration
 tools".


I've successfully upgraded Win 3.11 -> 95, 95 -> 98 and 98SE -> XP. Also 
The XP/Vista service packs have worked fine. There were some problems 
with display drivers when upgrading from 3.11. Modifying some inf file by 
hand fixed that.

You also mentioned that upgrading Ubuntu has always failed. I've noticed 
that if you wait few weeks after the new release, the automatic upgrade 
is more successful. Also the problems are rather minor - start terminal 
and write 'sudo dpkg ..something..; sudo aptitude update; sudo aptitude 
dist-upgrade'. My laptop has been running Ubuntu since 6.06 beta 
releases. I once tried Kubuntu, but went back to Ubuntu because of the 
stability issues (yea, a reformat even though removing kubuntu-desktop 
might have been enough).
Aug 19 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i4k3nr$alv$2 digitalmars.com...

 My laptop has been running Ubuntu since 6.06 beta
 releases. I once tried Kubuntu, but went back to Ubuntu because of the
 stability issues (yea, a reformat even though removing kubuntu-desktop
 might have been enough).


I recently upgraded my Linux box from Ubuntu 9.04 to Kubuntu 10.04 (I didn't 
attempt to do an in-place upgrade). It seems stable to me (although I don't 
use it as much as my primary system, so maybe there are issues I just 
haven't notced).

Well, except for one thing: I had a secondary hard drive in there, and the 
Kubuntu 10.04 installer kept crashing at the "select how you want your disks 
set up part". Unplugged it, installed Kubuntu just fine, and then plugged it 
back in. I didn't try to install Ubuntu 10.04 though, so for all I know it 
might not be Kubuntu-specific.
Aug 19 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 You also mentioned that upgrading Ubuntu has always failed. I've noticed 
 that if you wait few weeks after the new release, the automatic upgrade 
 is more successful. Also the problems are rather minor - start terminal 
 and write 'sudo dpkg ..something..; sudo aptitude update; sudo aptitude 
 dist-upgrade'. My laptop has been running Ubuntu since 6.06 beta 
 releases. I once tried Kubuntu, but went back to Ubuntu because of the 
 stability issues (yea, a reformat even though removing kubuntu-desktop 
 might have been enough).


My problems weren't minor, as in all my apps were completely hosed, including 
standard Ubuntu supplied stuff. It took me a long time googling to figure out 
how to get it to recognize my display again. The final straw was it completely 
trashed my install of VMware, wiping out all my virtual OS boxes. Bah. No more 
Ubuntu upgrades for me.

And before anyone asks, no, I was not running a tweaked Ubuntu system. It's all 
vanilla, right out of the box.
Aug 19 2010
prev sibling next sibling parent %u <e mail.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 On the other hand, OS X upgrades tend to be cheap ($25) while Windows upgrades
 tend to be expensive (hundreds of $).


Me like facts:

Windows 7 prof upgrade cost at walmart: 160$
(new oem is 100$)

10.1 	Puma 	2001
10.2 	Jaguar
10.3 	Panther
10.4 	Tiger
10.5 	Leopard
10.6 	Snow Leopard

XP      2001
Vista
7

The OS X releases are maybe more in line with Window's official releases +
service
packs.
Aug 17 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-17 15:18:12 -0400, Walter Bright <newshound2 digitalmars.com> said:


 (If Apple cared about this, there'd be nothing more than a switch to 
 g++ along the lines of -osx=10.4 and it'll do whatever is necessary to 
 build a backward compatible binary.)


Have you tried -isysroot ?

	gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk

Use it both when compiling and linking and you should get something 
10.5 compatible.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Aug 17 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:

 On 2010-08-17 15:18:12 -0400, Walter Bright <newshound2 digitalmars.com> 
 said:
 

 (If Apple cared about this, there'd be nothing more than a switch to 
 g++ along the lines of -osx=10.4 and it'll do whatever is necessary to 
 build a backward compatible binary.)


 
 Have you tried -isysroot ?
 
     gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk
 
 Use it both when compiling and linking and you should get something 10.5 
 compatible.



Naw, I needed to set the environment variable MACOSX_DEPLOYMENT_TARGET too. The 
point is, the Apple docs on this are spread out over unconnected
pages and they contradict each other.
Aug 19 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-17 21:18, Walter Bright wrote:

 Nick Sabalausky wrote:

 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.343.1282068838.13841.digitalmars-d puremagic.com...

 But he's a Mac user! :p


 Heh, that was exactly my thought ;) I'm not a mac user
 (nearly-immediate obsolescence is one of the reasons I left the Mac
 world after giving OSX a serious try for a couple years). My primary
 OS is ten years old (unless you count service packs), and I'm
 perfectly happy with it (well, much more happy than I would be with
 the newer versions of it, like Win7 - I swear, MS's devs are getting
 to be like Mozilla's).


 I'm using a 10 year old Windows XP version, but the difference between
 the Mac world and the Windows world is Microsoft cares about legacy
 compatibility, and my experience with Mac OS X 10.4 .. 10.6 is that
 Apple goes out of their way to make it difficult to build backwards
 compatible binaries.

 Take a look at the dmd makefiles for OS X. Worse, Apple's documentation
 on how to do this is contradictory and spread out over obscure web
 pages, so there's a fair amount of trial and error to get it set up
 right. (If Apple cared about this, there'd be nothing more than a switch
 to g++ along the lines of -osx=10.4 and it'll do whatever is necessary
 to build a backward compatible binary.)


It's called -mmacosx-version-min. Just add the version number like this:

gcc main.c -o main -mmacosx-version-min=10.5


 On the other hand, OS X upgrades tend to be cheap ($25) while Windows
 upgrades tend to be expensive (hundreds of $).



-- 
/Jacob Carlborg
Aug 18 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:

 It's called -mmacosx-version-min. Just add the version number like this:
 
 gcc main.c -o main -mmacosx-version-min=10.5


Not what Apple's web pages say to do.
Aug 19 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-17 19:35, lurker wrote:

 Walter Bright Wrote:


 Jacob Carlborg wrote:

 Please build the Mac version on Mac OS X 10.5 if possible otherwise it
 will only run on Mac OS X 10.6. This should really be fixed in possible.


 10.6 is over a year old, why not upgrade?


 It costs money - money doesn't grow on trees?


In this case the cost is not a problem, it's only $29.00.

-- 
/Jacob Carlborg
Aug 18 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-17 19:18, Walter Bright wrote:

 Jacob Carlborg wrote:

 Please build the Mac version on Mac OS X 10.5 if possible otherwise it
 will only run on Mac OS X 10.6. This should really be fixed in possible.


 10.6 is over a year old, why not upgrade?


I just haven't got around and do it on one of my computers. And I think 
that the compiler/application should at least support two versions of 
the OS.

-- 
/Jacob Carlborg
Aug 18 2010