View previous topic :: View next topic |
Author |
Message |
Gregor
Joined: 05 May 2006 Posts: 72 Location: Portland, OR
|
Posted: Fri Dec 22, 2006 9:25 am Post subject: |
|
|
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
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
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 |
|
|
Gregor
Joined: 05 May 2006 Posts: 72 Location: Portland, OR
|
Posted: Fri Dec 22, 2006 11:00 am Post subject: |
|
|
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 |
|
|
Gregor
Joined: 05 May 2006 Posts: 72 Location: Portland, OR
|
Posted: Fri Dec 22, 2006 11:03 am Post subject: |
|
|
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 |
|
|
sylverpyro
Joined: 23 May 2006 Posts: 28
|
Posted: Wed Jan 24, 2007 9:59 am Post subject: |
|
|
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:
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 |
|
|
Derek Parnell
Joined: 22 Apr 2004 Posts: 408 Location: Melbourne, Australia
|
Posted: Wed Jan 24, 2007 4:58 pm Post subject: |
|
|
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 |
|
|
tonyroberts09
Joined: 08 Jan 2009 Posts: 4
|
Posted: Thu Jan 08, 2009 12:29 pm Post subject: |
|
|
i think -op should work with gdmd (which is GDC with DMD command-line style arguments) |
|
Back to top |
|
|
|
|
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
|