View mode: basic / threaded / horizontal-split · Log in · Help
July 19, 2011
Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]
"James Fisher" <jameshfisher@gmail.com> wrote in message 
news:mailman.1733.1311010642.14074.digitalmars-d@puremagic.com...
> When writing Haskell and compiling with GHC, the compiler automatically
> finds the module dependencies and compiles them in the correct order.  If 
> I
> touch a few modules and recompile, GHC will only recompile the touched
> modules as appropriate, then re-link.  In other words, GHC is the build 
> tool
> as well as the compiler.  The advantages of this approach over having a
> separate build tool are:
>

In the context of the rest of this thread, "build tool" refers to something 
that can handle multiple targets, multiple configurations and custom build 
steps. So that doesn't sound like quite the same thing. D does already have 
RDMD which is equivalent to what you're talking about (and it uses the -deps 
flag Jacob mentioned to get the deps directly from the actual compiler).
July 19, 2011
Re: Prototype buildsystem "Drake"
"Jacob Carlborg" <doob@me.com> wrote in message 
news:j00krh$1i3q$1@digitalmars.com...
> On 2011-07-17 23:01, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message
>>> Ok, have you thought about how this will look (in code) and behave?
>>>
>>
>> Not extensively, but here's what I have in mind so far. In an early 
>> initial
>> version of Drake, it would be like this:
>>
>>      task("configure", "drake.conf");
>>
>>      file("drake.conf",
>>          (Target t)
>>          {
>>              // Do all configuring here and save to drake.conf
>>          }
>>      );
>
> Ok. Will the build script change the configuration file?

Yes.

> Seems kind of strange. Usually the config file is used to control the 
> build script, not the other way around.
>

It's not really "the other way around" since the buildscript would still 
load the configuration file and use the settings in it (I guess I neglected 
to mention that part). It's just that creating it isn't done separately from 
the buildscript like with the clunky autotools. From a quick browse through 
the docs, Waf seems to have the buildscript direct the creation of the 
configuration file, too.
July 19, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-19 04:51, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
>> Ok. Will the build script change the configuration file?
>
> Yes.
>
>> Seems kind of strange. Usually the config file is used to control the
>> build script, not the other way around.
>>
>
> It's not really "the other way around" since the buildscript would still
> load the configuration file and use the settings in it (I guess I neglected
> to mention that part). It's just that creating it isn't done separately from
> the buildscript like with the clunky autotools. From a quick browse through
> the docs, Waf seems to have the buildscript direct the creation of the
> configuration file, too.

I start to think that we mean different things when we say "config 
file". What would you have in the config file?

-- 
/Jacob Carlborg
July 19, 2011
Re: Prototype buildsystem "Drake"
"Jacob Carlborg" <doob@me.com> wrote in message 
news:j03fe0$101m$1@digitalmars.com...
> On 2011-07-19 04:51, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob@me.com>  wrote in message
>>> Ok. Will the build script change the configuration file?
>>
>> Yes.
>>
>>> Seems kind of strange. Usually the config file is used to control the
>>> build script, not the other way around.
>>>
>>
>> It's not really "the other way around" since the buildscript would still
>> load the configuration file and use the settings in it (I guess I 
>> neglected
>> to mention that part). It's just that creating it isn't done separately 
>> from
>> the buildscript like with the clunky autotools. From a quick browse 
>> through
>> the docs, Waf seems to have the buildscript direct the creation of the
>> configuration file, too.
>
> I start to think that we mean different things when we say "config file". 
> What would you have in the config file?
>

Granted, I've never used this sort of feature from any buildsystem, but I 
thought we were talking about something like the "configure" command in Waf. 
My understanding is that it's like the "./configure" from autotool's 
"./configure && make && make install", (except hopefully without needing to 
check quite so much stuff or needing the user to manually run the configure 
command).

Apperently some projects need to have their buildsystem check for the 
existance of, locations of, and details about certain things on the local 
system before building. So...that stuff.
July 19, 2011
Re: Prototype buildsystem "Drake"
On Tue, 2011-07-19 at 05:28 -0400, Nick Sabalausky wrote:
[ . . . ]
> Granted, I've never used this sort of feature from any buildsystem, but I 
> thought we were talking about something like the "configure" command in Waf. 
> My understanding is that it's like the "./configure" from autotool's 
> "./configure && make && make install", (except hopefully without needing to 
> check quite so much stuff or needing the user to manually run the configure 
> command).

Waf does indeed have a configure phase and a build phase.  As long as
the configuration remains unchanged after a "waf configure" and there
hasn't been a "waf distclean" then you only ever need to build.

SCons on the other hand runs all the configuration checks in the
SConscript file on every run.

I am never sure which I prefer, they both have positives and negatives.

> Apperently some projects need to have their buildsystem check for the 
> existance of, locations of, and details about certain things on the local 
> system before building. So...that stuff.

I would have thought this would be all projects that are distributed as
source?
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 19, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-19 11:28, Nick Sabalausky wrote:
> Granted, I've never used this sort of feature from any buildsystem, but I
> thought we were talking about something like the "configure" command in Waf.
> My understanding is that it's like the "./configure" from autotool's
> "./configure&&  make&&  make install", (except hopefully without needing to
> check quite so much stuff or needing the user to manually run the configure
> command).

I would hope D never had to use something like "./configure". It checks 
for C language features and similar (probably other things as well). I 
don't think that that belongs in a build system for D.

> Apperently some projects need to have their buildsystem check for the
> existance of, locations of, and details about certain things on the local
> system before building. So...that stuff.

Isn't that to check what libraries, and so on, are present? That is the 
whole point of a package manager. A package specifies what dependencies 
it has, then the package manager makes sure the dependencies are met, or 
else it can't be installed.

Don't know what locations it would check for. The package as no saying 
in where it should be installed, the package manger decides that.

Oh, now I mixing package manager and build tool and assume the build 
tool will be used with the package manager.

When I was talking about "config file" I was thinking something more 
like Rebuild's config files, example: http://pastebin.com/rYc47wXQ

-- 
/Jacob Carlborg
July 19, 2011
Re: Prototype buildsystem "Drake"
2011/7/19 Jacob Carlborg <doob@me.com>:
>> Apperently some projects need to have their buildsystem check for the
>> existance of, locations of, and details about certain things on the local
>> system before building. So...that stuff.
>
> Isn't that to check what libraries, and so on, are present? That is the
> whole point of a package manager. A package specifies what dependencies it
> has, then the package manager makes sure the dependencies are met, or else
> it can't be installed.

All "dependencies" aren't always mandatory. It's not uncommon for some
software to adapt itself to the environment, say enabling certain
features IF certain other packages can be found, otherwise just
disable the functionality. Also it might adapt itself on other
conditions, say auto-detecting checking what OS-kernel we are building
for, and pass along D versions-keywords accordingly, including
allowing the user to override, to do cross-platform or cross-version
builds. Also, most build-systems offers options for whomever is
building, such as --use-test-codeX, much like Tango now allows you to
build with the regular, or the less tested concurrent GC.

> Don't know what locations it would check for. The package as no saying in
> where it should be installed, the package manger decides that.
Same here. You may have multiple builds of the same package, and want
to cross test a dependent package against two different installs to do
regression-testing. (Or the classic i386/x86_64 debacle)

> Oh, now I mixing package manager and build tool and assume the build tool
> will be used with the package manager.
I think the build-tool and package manager must be independent, but
well integrated. Otherwise, you risk making it difficult for
D-software to come by default in Linux-distros, and you make it
difficult for the D-package-manager to carry a package with a
different build-system (even a D based package with different
build-system).
July 19, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-19 15:48, Ulrik Mikaelsson wrote:
> 2011/7/19 Jacob Carlborg<doob@me.com>:
>>> Apperently some projects need to have their buildsystem check for the
>>> existance of, locations of, and details about certain things on the local
>>> system before building. So...that stuff.
>>
>> Isn't that to check what libraries, and so on, are present? That is the
>> whole point of a package manager. A package specifies what dependencies it
>> has, then the package manager makes sure the dependencies are met, or else
>> it can't be installed.
>
> All "dependencies" aren't always mandatory. It's not uncommon for some
> software to adapt itself to the environment, say enabling certain
> features IF certain other packages can be found, otherwise just
> disable the functionality. Also it might adapt itself on other
> conditions, say auto-detecting checking what OS-kernel we are building
> for, and pass along D versions-keywords accordingly, including
> allowing the user to override, to do cross-platform or cross-version
> builds. Also, most build-systems offers options for whomever is
> building, such as --use-test-codeX, much like Tango now allows you to
> build with the regular, or the less tested concurrent GC.

Ok, I see.

>> Don't know what locations it would check for. The package as no saying in
>> where it should be installed, the package manger decides that.
> Same here. You may have multiple builds of the same package, and want
> to cross test a dependent package against two different installs to do
> regression-testing. (Or the classic i386/x86_64 debacle)
>
>> Oh, now I mixing package manager and build tool and assume the build tool
>> will be used with the package manager.
> I think the build-tool and package manager must be independent, but
> well integrated. Otherwise, you risk making it difficult for
> D-software to come by default in Linux-distros, and you make it
> difficult for the D-package-manager to carry a package with a
> different build-system (even a D based package with different
> build-system).

The package manager and build system will be independent. I just got 
confuse and it was a mess in my head :). Was unsure if what I wrote 
would make any sense.

-- 
/Jacob Carlborg
July 19, 2011
Re: Prototype buildsystem "Drake"
On Tue, 2011-07-19 at 14:55 +0200, Jacob Carlborg wrote:
> On 2011-07-19 11:28, Nick Sabalausky wrote:
> > Granted, I've never used this sort of feature from any buildsystem, but I
> > thought we were talking about something like the "configure" command in Waf.
> > My understanding is that it's like the "./configure" from autotool's
> > "./configure&&  make&&  make install", (except hopefully without needing to
> > check quite so much stuff or needing the user to manually run the configure
> > command).
> 
> I would hope D never had to use something like "./configure". It checks 
> for C language features and similar (probably other things as well). I 
> don't think that that belongs in a build system for D.

Well Autoconf, Waf and SCons check for a whole lot more than C features,
there are C++, Fortran, Python, . . . but yes one part of configuration
is (not unreasonably) which version of which languages are available in
order to build from source.

> > Apperently some projects need to have their buildsystem check for the
> > existance of, locations of, and details about certain things on the local
> > system before building. So...that stuff.
> 
> Isn't that to check what libraries, and so on, are present? That is the 
> whole point of a package manager. A package specifies what dependencies 
> it has, then the package manager makes sure the dependencies are met, or 
> else it can't be installed.

There is clearly a string coupling between configuration and package
management.   Autoconf, Waf and SCons have to be portable across package
management since they are not dedicated to one scheme -- springing up as
they did from before package management as standard.

> Don't know what locations it would check for. The package as no saying 
> in where it should be installed, the package manger decides that.
> 
> Oh, now I mixing package manager and build tool and assume the build 
> tool will be used with the package manager.

There are some potentially tricky issues here.  Ruby gets round it by
having a language specific package and build system which therefore
causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
language packaging and platform packaging is central.  Having a D
language packaging system that was in some way harmonious with Apt/Deb,
Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
it would make traction a whole lot easier.  As evidence I present Java,
Ruby, Python, Haskell, etc.

> When I was talking about "config file" I was thinking something more 
> like Rebuild's config files, example: http://pastebin.com/rYc47wXQ
> 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 19, 2011
Re: Prototype buildsystem "Drake"
On 2011-07-19 16:46, Russel Winder wrote:
> There is clearly a string coupling between configuration and package
> management.   Autoconf, Waf and SCons have to be portable across package
> management since they are not dedicated to one scheme -- springing up as
> they did from before package management as standard.

Ok.

> There are some potentially tricky issues here.  Ruby gets round it by
> having a language specific package and build system which therefore
> causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
> headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
> language packaging and platform packaging is central.  Having a D
> language packaging system that was in some way harmonious with Apt/Deb,
> Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
> it would make traction a whole lot easier.  As evidence I present Java,
> Ruby, Python, Haskell, etc.

The whole point of having a D package manager is so I don't have to 
create packages for all these system specific package managers.

-- 
/Jacob Carlborg
6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home