FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Object files going to working directory (GDC, Mac OS X 10.3)
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Build
View previous topic :: View next topic  
Author Message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Wed Dec 20, 2006 5:36 am    Post subject: Object files going to working directory (GDC, Mac OS X 10.3) Reply with quote

I'm having a little problem with bud and GDC on my Mac. The problem is that although my project compiles correctly, all the .o files get placed in the source directory. This is very bad, because some of my modules have the same name and they tend to overwrite each other, which wreaks havoc in the linking stage (the linker complains about "multiple definitions" and such).

This has been mentioned before but I can't find a fix or a workaround, apart from adding the -op switch - but this doesn't work in gdc, which is a killer problem for me since gdc is the only compiler that works on the Mac.

Doesn't bud run a separate instance of gdc/dmd for each and every .d file that it decides to compile? If so, couldn't it just tell the compiler to put the .o file in the desired directory? Or am I misunderstanding how it works? (I tried to read the source code to figure this out, but at 3655 lines it's a bit hard for me to digest.)

If not, I guess the only solution is to petition the gdc guys to add the -op switch (or similar). I'm curious as to why this hasn't been done already, but I'm happy to lead the charge if that's what it takes (because to be quite frank, this situation sucks).
Back to top
View user's profile Send private message
Auria



Joined: 29 May 2006
Posts: 44

PostPosted: Wed Dec 20, 2006 9:34 am    Post subject: Reply with quote

i think -op should work with gdmd (which is GDC with DMD command-line style arguments)
Back to top
View user's profile Send private message
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Wed Dec 20, 2006 3:31 pm    Post subject: Reply with quote

Crispy wrote:
I'm having a little problem with bud and GDC on my Mac. The problem is that although my project compiles correctly, all the .o files get placed in the source directory. This is very bad, because some of my modules have the same name and they tend to overwrite each other, which wreaks havoc in the linking stage (the linker complains about "multiple definitions" and such).

This has been mentioned before but I can't find a fix or a workaround, apart from adding the -op switch - but this doesn't work in gdc, which is a killer problem for me since gdc is the only compiler that works on the Mac.

I'm one of the unfortunate people that have yet to own a Mac - so this is not a problem that I was very aware of.
Quote:

Doesn't bud run a separate instance of gdc/dmd for each and every .d file that it decides to compile? If so, couldn't it just tell the compiler to put the .o file in the desired directory? Or am I misunderstanding how it works? (I tried to read the source code to figure this out, but at 3655 lines it's a bit hard for me to digest.)

No Bud doesn't work like that. It uses the DMD concept of compiling all the files on the command line with one execution of the compiler. I could add an option to force Bud to work that way though.
Quote:

If not, I guess the only solution is to petition the gdc guys to add the -op switch (or similar). I'm curious as to why this hasn't been done already, but I'm happy to lead the charge if that's what it takes (because to be quite frank, this situation sucks).

I would support that petition too.
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
Auria



Joined: 29 May 2006
Posts: 44

PostPosted: Wed Dec 20, 2006 8:42 pm    Post subject: Reply with quote

Quote:
If not, I guess the only solution is to petition the gdc guys to add the -op switch (or similar). I'm curious as to why this hasn't been done already, but I'm happy to lead the charge if that's what it takes (because to be quite frank, this situation sucks).


Though we'd be nicer if we provided a patch rather than petitioning Laughing
Back to top
View user's profile Send private message
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Wed Dec 20, 2006 8:55 pm    Post subject: Reply with quote

Auria wrote:
Quote:
If not, I guess the only solution is to petition the gdc guys to add the -op switch (or similar). I'm curious as to why this hasn't been done already, but I'm happy to lead the charge if that's what it takes (because to be quite frank, this situation sucks).


Though we'd be nicer if we provided a patch rather than petitioning Laughing

Except that I'm not capable of doing that Wink
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Thu Dec 21, 2006 12:27 am    Post subject: Reply with quote

Auria - Yes, gdmd supports -op, however bud doesn't (AFAIK) support gdmd. Which would be nice...

(The reason that gdmd supports -op is because it actually loops through the list of provided source files and calls gdc on each one individually.)

I would work on a patch, but I have zero experience with compilers.

Quote:
I'm one of the unfortunate people that have yet to own a Mac - so this is not a problem that I was very aware of.


I can sympathise; I got my only Mac (a 1998-era iMac) just recently. My workplace was about to throw it out, so I saved it. (Though from the sound of the power supply it's in its death throes anyway.)

I thought a similar problem was encountered under Linux at one stage?

Quote:
No Bud doesn't work like that. It uses the DMD concept of compiling all the files on the command line with one execution of the compiler. I could add an option to force Bud to work that way though.


I see. Well, such an option would definitely be nice. Being able to use gdmd (and thus pass the -op switch) would be nicer though. Wink

Perhaps I should make a patch for bud that gives the option to use gdmd... that has to be the easiest solution.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Dec 21, 2006 12:37 pm    Post subject: Reply with quote

Someone on #D told me that you just rename the script "gdmd" to "dmd" to get bud to work with it (in order to use -op). I hadn't got around to trying it, but the person who told me uses a mac and said it worked. I was taken completely by surprise with that simple solution. No need to hack in gdmd support if it's already there. And I had never even thought of it. Smile

But I agree: it would be nice if bud or gdc added the "-op" flag. The problem is not mac only, but occurs in all gdc implementations as far, as I know. Objects in the D language just shouldn't be placed in the same directory. The problem is that dmd works differently than gdc. gdc still seems to operate in terms of its gcc/C heritage.

I also agree that the proper place for the fix is in gdc instead of bud... but if bud could include a feature to compile single project modules iteratively (much like gcc does with C source), that might be something to try. The drawback is that it may surface a whole new set of problems.

I think we should at least put in a request for "-op" on the d.gnu group and see what can be done.

-JJR
Back to top
View user's profile Send private message
Gregor



Joined: 05 May 2006
Posts: 72
Location: Portland, OR

PostPosted: Thu Dec 21, 2006 1:22 pm    Post subject: Reply with quote

I think the easy solution would be to use gdmd from bu[il]d instead of gdc. If you'd like, I'll write the changes/patch.
Back to top
View user's profile Send private message AIM Address
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Dec 21, 2006 2:22 pm    Post subject: Reply with quote

agreed.

Gregor, it would be great if Derek would accept the patch.

-JJR
Back to top
View user's profile Send private message
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Thu Dec 21, 2006 5:49 pm    Post subject: Reply with quote

JJR wrote:
agreed.

Gregor, it would be great if Derek would accept the patch.

-JJR

NO NO NO !!!!!

This is why there is a Bud configuration file. There is no need to patch the source code!!!!! Just create a configuration file that support gdmd rather than gdc. DO NOT PATCH THE SOURCE CODE

I'll give it a go later today and you'll see how easy it is.
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
Crispy



Joined: 26 Nov 2005
Posts: 67

PostPosted: Thu Dec 21, 2006 6:15 pm    Post subject: Reply with quote

Settle down, Derek. Laughing

In fact, I already hacked the source code yesterday to make it use gdmd instead of gdc. It's quick and ugly and, well, a hack - but it works! Still, I won't bother sharing the patch if that's the reaction I'll get. Wink A configuration file is definitely a better way to do it anyway.

Adding an equivalent to -op in gdc is something that should happen, for sure - this is a problem that needs to be tackled at its source.
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Dec 21, 2006 6:32 pm    Post subject: Reply with quote

Come to think of it... I wonder why "-op" isn't the default in dmd and gdc. It seems that making the flag optional is a mistake in terms of how the Language works. In dmd, it seems that the flag is not always necessary merely because dmd has the capability of compiling everything on a single commandline. But this assumption is fairly compiler specific.

I think the flag should be removed and the functionality implemented in dmd and gdc as the default state. Perhaps this is something that should be discussed in the d.gnu group as well.

In the meantime, though, Gregor's solution is adequate.

-JJR
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Dec 21, 2006 6:47 pm    Post subject: Reply with quote

Derek Parnell wrote:
JJR wrote:
agreed.

Gregor, it would be great if Derek would accept the patch.

-JJR

NO NO NO !!!!!

This is why there is a Bud configuration file. There is no need to patch the source code!!!!! Just create a configuration file that support gdmd rather than gdc. DO NOT PATCH THE SOURCE CODE

I'll give it a go later today and you'll see how easy it is.


No, Derek. It is a pain. If you can give it a go with a config file and make it work, I'd be happy to see how you did it. I'd also be curious to see how it works for a large number of projects on Mac and Linux using gdc.

I assure you that creating a config file to support gdmd was one of the first things I tried. And it didn't work. Naturally, I might have done something wrong and maybe you'll get better mileage.

Furthermore, using gdmd or aliasing gdmd to dmd are merely temporary solutions for forcing bud to work with gdc. It would be better if bud could get fully working with gdc. And it doesn't appear that a config file is sufficient to fix that (ie... whole -op discussion). We need one of the following: single module compile mode for bud, integrated -op on all compilers, or -op added to gdc.

-JJR
Back to top
View user's profile Send private message
Gregor



Joined: 05 May 2006
Posts: 72
Location: Portland, OR

PostPosted: Thu Dec 21, 2006 9:40 pm    Post subject: Reply with quote

I understand your love for configuration files, Derek. Really, I do.

But I don't like using configuration files in bud, because their implementation is horrible on several counts:

1) There are several things version()'d in bud's source which are unconfigurable, such as adding the Posix flag.
2) If I correctly recall, it only looks for the configuration file in the same directory as bud itself. This may be OK on Windows, but on literally every other OS in existance this is just ridiculous. It should look in <bud's path>/../etc, ~/.build and /etc at least.
3) You have defaults in bud for things that ought to be in the configuration files. This means that using bud doesn't require a configuration file, so nobody would ever set one up unless they had specific needs. -op is not a specific need, it's a general need - people WILL be compiling software they didn't write, and it WILL fail to compile without -op due to the author's intent. Either the defaults in build.d should be something everybody can be reasonably happy with, or there should be no defaults in build.d and the configuration files should be something everybody can be happy with.
Back to top
View user's profile Send private message AIM Address
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Fri Dec 22, 2006 12:06 am    Post subject: Reply with quote

Gregor wrote:
I understand your love for configuration files, Derek. Really, I do.
Yeah... sure you do ...
Gregor wrote:
But I don't like using configuration files in bud, because their implementation is horrible on several counts:

So let's make them not horrible.
Gregor wrote:

1) There are several things version()'d in bud's source which are unconfigurable, such as adding the Posix flag.

Sorry, lost you here. Why doesn't "-version=Posix" work for you? However, if any of "unix", "Unix", "linux" or "darwin" have been defined then Bud also defines "Posix" as a version automatically.

Gregor wrote:
2) If I correctly recall, it only looks for the configuration file in the same directory as bud itself. This may be OK on Windows, but on literally every other OS in existance this is just ridiculous. It should look in <bud's path>/../etc, ~/.build and /etc at least.

I wonder why we bother with writing documentation at all. If you care to check it out you will read ...
Quote:

The utility's configuration file is used to specify your default options for the utility. The file is called build.cfg. You can have from zero to four configuration files because the Bud utility looks in each of four places for a configuration file, and it uses each one that it finds. It looks in the folder that Bud is installed, then in a user defined alternative path (defined by -BCFPATH switch), then in the folder that the compiler is installed, and finally in the current folder.

Note: The alternative location is optional. It can be specified in an environment switch called BCFPATH or in a command line switch of the same name, -BCFPATH.

I'm not a big user of Unix so I'm not always aware its many unwritten conventions. But now that you have so graciously requested for alternative locations to be inspected, I will add them to the tool.
Gregor wrote:
3) You have defaults in bud for things that ought to be in the configuration files. This means that using bud doesn't require a configuration file, so nobody would ever set one up unless they had specific needs.
Exactly! That's why configuration files are optionally available.

Gregor wrote:
-op is not a specific need, it's a general need - people WILL be compiling software they didn't write, and it WILL fail to compile without -op due to the author's intent. Either the defaults in build.d should be something everybody can be reasonably happy with, or there should be no defaults in build.d and the configuration files should be something everybody can be happy with.
Your non-DigitalMars unix coloured glasses may be confusing you.

However, in the spectrum that ranges from "everybody happy" to "nobody happy", I've choosen to pick "most people happy". So shoot me.

The -op switch is the default if you are using DigitalMars tools. As -op is a DigitalMars switch it seems dumb to make it the default when using non-DigitalMars tools such as gdc (which doesn't support it anyhow) and gdmd is not a DigitalMars tool either. So in the rare situation where someone is using gdmd, I figure they can put it into their personal build.cfg file and have their cake as well.

Here is a config file that should support gdmd, if the docs regarding gdmd are accruate.

Code:

CMDLINE=-version=Posix
CMDLINE=-op
INIT:ExeExtension    =
INIT:LibExtension    =  a
INIT:ObjExtension    =  o
INIT:ShrLibExtension =  so
INIT:SrcExtension    =  d
INIT:MacroExtension  =  mac
INIT:DdocExtension   =  ddoc
INIT:CompilerExe     =  gdmd
INIT:CompileOnly     =  -c
INIT:LinkerExe       =  gdmd
INIT:ConfigFile      =  dmd.conf
INIT:ConfigPath      =  /etc/
INIT:CompilerPath    =
INIT:LinkerPath      =
INIT:LinkerDefs      =
INIT:LibPaths        =
INIT:ConfigSep       =  :
INIT:Librarian       =  ar
INIT:LibrarianOpts   =  -r
INIT:VersionSwitch   =  -version
INIT:DebugSwitch     =  -debug
INIT:OutFileSwitch   =  -of
INIT:ImportPath      =  -I
INIT:LinkLibSwitch   =  -l
INIT:LibPathSwitch   =  -L
INIT:MapSwitch       =  -M
INIT:SymInfoSwitch   =  /co
INIT:BuildImportPath =  -I
INIT:ImportPathDelim =  ;
INIT:OutputPath      =  -od
INIT:RunSwitch       =  -exec
INIT:LibrarianPath   =
INIT:ResponseExt     =  brf
INIT:DefResponseFile =  build.brf
INIT:RDFName         =  default.rdf
INIT:DefMacroDefFile =  build.mdf
INIT:LinkerStdOut      =  ` >/dev/null`
INIT:IgnoredModules  =
INIT:AssumedLibs     =
INIT:PathId          = PATH
INIT:ModOutPrefix    = "MODULES =\n"
INIT:ModOutSuffix    =
INIT:ModOutBody      = "    $(MODULE {mod})\n"
INIT:ModOutDelim     =
INIT:ModOutFile      = _modules.ddoc
INIT:GenDebugInfo    = -g
INIT:CompilerDefs    =
INIT:HomePathId      = HOME
INIT:EtcPath         = /etc/
INIT:ArgDelim        = " "
INIT:ArgFileDelim    = " "
INIT:PostSwitches    = No
INIT:AppendLinkSwitches = No

If this doesn't do it, please tell me what aspects are not working so I can improve things. I really don't want to load this on a linux machine here because it is just so bloody hard to do. I'm never sure where things are supposed to go or where they are actually installed into. I never know what needs compiling, etc... Windows just makes things so much easier for me that I shudder when I have to regress into using linux.
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Build All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group