July 19, 2011
"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
"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
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
"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
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
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
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
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
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
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