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 Previous  1, 2
 
Post new topic   Reply to topic     Forum Index -> Build
View previous topic :: View next topic  
Author Message
Gregor



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

PostPosted: Fri Dec 22, 2006 9:25 am    Post subject: Reply with quote

My apologies on the tone of my last post.

Derek Parnell wrote:
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.


If you'll accept patches, I'll gladly write them. I'm a jerk, but I really would like to help Smile

Derek Parnell wrote:
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.


For one, it's a compiler-specific flag: It makes -fversion or -version. So the configuration files are rendered not powerful enough to change from one compiler to another.

For two, it makes cross-compilation impossible.

Derek Parnell wrote:
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.


-BCFPATH or $BCFPATH require user intervention. They're an added feature, but not a convenient default.

I realize you're not Unix-native. Thank you for tolerating my tone Smile

Derek Parnell wrote:
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.


If they grab a piece of software libfoo, compiled by the author with DMD, and set up in such a way that it absolutely requires -op, average-user-X will just be confused. It's a really confusing moment, seeing that particular break.

Derek Parnell wrote:
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.


1) Your intolerance is clearly defined by bad history. The truth is that there are good distributions, and there are bad distributions. I'd try Mandriva. You won't compile anything, and the installation is a breeze. If you've used Gentoo or Slackware as a first-time-Unixer, I'm sorry, but really, there are more friendly distributions out there.

2) I'll try it, but can't right now. I'll post later.

3) If this works so well, why can't it be default? It would give people the ability to use -op everywhere, and tear down one more difference. I think your view is that the person compiling a piece of software will likely be the person who wrote it - in my view, it's at least as often some other person, so the defaults, IMHO, should strive to maximize compatibility.
Back to top
View user's profile Send private message AIM Address
Gregor



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

PostPosted: Fri Dec 22, 2006 11:00 am    Post subject: Reply with quote

Here's a working CFG file:

Code:
CMDLINE=-version=Posix
CMDLINE=-op
CMDLINE=-UMB=no
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      = 
INIT:ConfigPath      = 
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-l
INIT:LibPathSwitch   =  -L-L
INIT:MapSwitch       =  -M
INIT:SymInfoSwitch   =  -g
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


The changes I made:
1) gdmd does not have a dmd.conf
2) -UMB no


For your information, here's the chunk of code that make cross-compilation utterly impossible:

Code:
// -------------------------------------------
void SetKnownVersions()
// -------------------------------------------
{

    version(DigitalMars)  ActivateVersion("DigitalMars");
    version(X86)          ActivateVersion("X86");
    version(PPC)          ActivateVersion("PPC");
    version(AMD64)        ActivateVersion("AMD64");
    version(PPC64)        ActivateVersion("PPC64");
    version(Windows)      ActivateVersion("Windows");
    version(Win32)        ActivateVersion("Win32");
    version(Win64)        ActivateVersion("Win64");
    version(linux)        ActivateVersion("linux");
    version(darwin)       ActivateVersion("darwin");
    version(Unix)         ActivateVersion("Unix");
    version(unix)         ActivateVersion("unix");
    version(Posix)        ActivateVersion("Posix");
    version(LittleEndian) ActivateVersion("LittleEndian");
    version(BigEndian)    ActivateVersion("BigEndian");
    version(D_InlineAsm)  ActivateVersion("D_InlineAsm");

    version(BuildVerbose)
    {
        ActivateVersion("BuildVerbose");
        if (vVerboseMode == True)
            foreach(string k; vActiveVersions.keys){
                writefln("Active Version: '?s'", k);
            }
    }
}


Maybe X-cc with build is a pipe dream, but don't you agree that it's not good to allow configuration of the compiler but then cut off all configuration of this? Even something like a versions="This That TheOtherThing" would be fine if it completely neutered this bit. Again: I'll write the patch, if you'd like.
Back to top
View user's profile Send private message AIM Address
Gregor



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

PostPosted: Fri Dec 22, 2006 11:03 am    Post subject: Reply with quote

Oh, I should also mention: My complaint about it adding -version=Posix of -fversion=Posix: The code that did that has apparently since been moved, so I apologize, I was working off of memory.
Back to top
View user's profile Send private message AIM Address
sylverpyro



Joined: 23 May 2006
Posts: 28

PostPosted: Wed Jan 24, 2007 9:59 am    Post subject: Reply with quote

Quote:

The -op switch is the default if you are using DigitalMars tools. As -op


This actaully is incorrect, dmd 1.00 on a P4 Ubuntu Linux box that I own does not inherently use -op if invoked from the command line.

Initial folder contents:
Code:

build.cfg  compile.sh  modules  RoadMap.txt  smUtil  smUtil.d  testFiles

./modules/ksf/ksfFolder.d
./modules/ksf/ksfChart.d
./modules/ksf/.svn


Command run:
Code:

~# dmd /modules/ksf/ksfChart.d


New folder content:
Code:

build.cfg  compile.sh  ksfChart.o  modules  RoadMap.txt  smUtil  smUtil.d  testFiles

./modules/ksf/ksfFolder.d
./modules/ksf/ksfChart.d
./modules/ksf/.svn


Now with the -op switch:
Code:

~# dmd -op /modules/ksf/ksfChart.d


Resulting content:
Code:

build.cfg  compile.sh  modules  RoadMap.txt  smUtil  smUtil.d  testFiles

./modules/ksf/ksfFolder.d
./modules/ksf/ksfChart.d
./modules/ksf/ksfChart.o
./modules/ksf/.svn


-op is also not a default when using build it appears

Config file (commented out -op to show effect):]
Code:

[Posix:GNU]
#CMDLINE=-op
CMDLINE=-release        ## This is to work around the std.boxer bug (issue 8 at digitalmars)
CMDLINE=-cleanup

[Posix:DigitalMars]
#CMDLINE=-op
CMDLINE=-I/home/sylverpyro/Software/Linux/D/DMD/dmd1.00/dmd/src/phobos
CMDLINE=-release        ## This is to work around the std.boxer bug (issue 8 at digitalmars)
CMDLINE=-cleanup

[darwin]
CMDLINE=-cleanup


Command run:
Code:

~# build smUtil.d


Resulting folder contents:
Code:

build.cfg   ksfChart.o   modules      smChart.o   smHeader.o  smUtil.d
compile.sh  ksfFolder.o  RoadMap.txt  smFolder.o  smUtil      testFiles


At this pont dmd exits as it complains it cannot find ./modules/ksf/*.o (any of the object files that it expects to be in those folders)

I am using build 3.04 also if that helps at all.

Oh, and as a note, when building with GDC on my Mac (as you can see in the build.cfg above) gdc inherently has the equivilent of the -op switch already enabled
Back to top
View user's profile Send private message
Derek Parnell



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

PostPosted: Wed Jan 24, 2007 4:58 pm    Post subject: Reply with quote

sylverpyro wrote:
Quote:

The -op switch is the default if you are using DigitalMars tools. As -op


This actaully is incorrect, dmd 1.00 on a P4 Ubuntu Linux box that I own does not inherently use -op if invoked from the command line.

You're right! Its only the default if you are running on Windows and have not provided a -INIT:CompilerDefs line in the config file.
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
tonyroberts09



Joined: 08 Jan 2009
Posts: 4

PostPosted: Thu Jan 08, 2009 12:29 pm    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
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Build All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 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