On 03-04-2012 10:23, Andrew Wiley wrote:
> On Tue, Apr 3, 2012 at 1:37 AM, Alex Rønne Petersen<xtzgzorex@gmail.com>  wrote:
>> On 03-04-2012 04:35, Andrew Wiley wrote:
>>>
>>> On Mon, Apr 2, 2012 at 9:04 PM, Alex Rønne Petersen<xtzgzorex@gmail.com>
>>>   wrote:
>>>>
>>>> On 03-04-2012 01:19, Joseph Rushton Wakeling wrote:
>>>>
>>>>>
>>>>> On 03/04/12 00:48, Alex Rønne Petersen wrote:
>>>>>>
>>>>>>
>>>>>> The Waf meta build system has good support for both GDC and LDC.
>>>>>
>>>>>
>>>>>
>>>>> I'm reluctant to use Waf due to the issues described here ... :-(
>>>>> http://lists.debian.org/debian-devel/2010/02/msg00714.html
>>>>>
>>>>
>>>> Which ones in particular? Debian lacking a system-level Waf doesn't seem
>>>> like a huge issue to me.
>>>>
>>>
>>> Unless you want someone else to build your software.
>>
>>
>> Include the Waf binary with your software. It's designed to be small so that
>> you can do this.
>>
>>
>>> My biggest frustration with open source software and specifically with
>>> meta build systems is that I don't want to learn a scripting language
>>> or a scripting language's package manager just to build and use a
>>> piece of software in a completely unrelated language, and if there's
>>> no pre-packaged version of a build system, I'm not going to take the
>>> time to figure out how to use whatever package manager language X uses
>>> to install that build system and all dependencies. Most likely the
>>> dependencies and build system will wind up in my home directory, which
>>> is hackish at best, and it'll all sit there forever and clutter up my
>>> home directory because I'll never touch that package manager again.
>>> For a build that will be set up exactly once and modified extremely
>>> rarely after the first month or so, how is this an improvement over
>>> this Makefile that can already do perfect incremental builds:
>>>
>>> TARGET  := someexecutable
>>> SRCS    := $(shell find -type f -name '*.d')
>>> OBJS    := ${SRCS:.d=.o}
>>> DEPS    := ${SRCS:.d=.dep}
>>> XDEPS   := $(wildcard ${DEPS})
>>> DC      := gdc
>>>
>>> DFLAGS = -Wall -Werror -g -O2
>>> LDFLAGS =
>>> LIBS    = -lpthread
>>>
>>> .PHONY: all clean distclean
>>> all:: ${TARGET}
>>>
>>> ifneq (${XDEPS},)
>>> include ${XDEPS}
>>> endif
>>>
>>> ${TARGET}: ${OBJS}
>>>      ${DC} ${LDFLAGS} ${DFLAGS} -o $@ $^ ${LIBS}
>>>
>>> ${OBJS}: %.o: %.d %.dep
>>>      ${DC} ${DFLAGS} -o $@ -c $<
>>>
>>> ${DEPS}: %.dep: %.d
>>>      ${DC} ${DFLAGS} -fsyntax-only -fmake-mdeps=$@ $<
>>>      sed -i 's:$(notdir ${<:.d=.o}):${<:.d=.o}:g' $@
>>>
>>> clean::
>>>      -rm -f ${OBJS} ${DEPS} ${TARGET}
>>>
>>> distclean:: clean
>>
>>
>> I understand your frustration about having to learn another language.
>> Learning a language is always an expensive task. But people don't
>> necessarily know Make syntax, just as they don't necessarily know Python, or
>> whatever (and I might add that Make can get very frustrating - the
>> requirement to use hard tabs is extremely annoying and unintuitive).
>>
> Either way, you're going to set up your build system once and rarely
> change it, so the syntax isn't really what bothers me. What matters
> isn't really the difficulty of setting up the build system, it's the
> difficulty of going from blank slate to finished binary for someone
> who has just downloaded the code. For better or worse, systems like
> make are ubiquitous, whereas with other build systems, I have to go
> install it. That still isn't too bad if there's a package I can
> install in the package manager I already use to manage my system, but
> when the developers actively discourage that convenience, I become
> concerned.

With Waf, the idea is that the Waf binary sits in your source control repository, so building is easy.

>
>> A problem with systems like Make is that it is hard to keep Makefiles
>> portable. It doesn't take much to accidentally introduce some sort of
>> platform/shell/compiler dependency. Python, as a programming language, at
>> least helps abstract most of these things away (for instance, shell syntax).
>
> Thanks to MSYS/MinGW, that Makefile I quoted runs on both Windows and
> Linux. It depends on find and sed. The dependency on find is easily
> removed if you're not too lazy to list source files like I am, and the
> sed dependency can be removed if you don't care too much about perfect
> incremental builds (there's probably a Windows shell equivalent, I
> haven't checked).
> I don't have a Mac, but I wouldn't expect sed/find to be an issue there.

It's a trivial Makefile. If you begin to add packaging, testing, etc then Makefiles become hell very quickly.

>
>> Anyway, as for what 'language' to use, it all comes down to your personal
>> situation. If you know Python, using something like Waf is completely
>> inexpensive, just as using Make is inexpensive if you know the Make syntax.
>
> I don't know Make syntax and I have no interest in learning it. What
> you see above was cobbled together once from a variety of online
> sources, tested thoroughly, and reused abusively because the only
> thing necessary to use it was to copy it to a new project. No large
> language installations, no oversized frameworks or tools. It works
> with most linux distributions out of the box, and on Windows you
> already have to install GCC (which includes make) to get GDC.

But that also indicates that you're going to have trouble the moment you decide to go further and add packaging, testing, documentation generation of sorts, etc.

I'm not sure if you're getting at Waf specifically here, but if you are, I don't think that's quite fair, since Waf is ~85 KB and is meant to sit in your source control repository. Also, Waf works on Windows/Linux/Mac (I have tested this), and probably many other systems where Python and a D compiler exists.

You might argue that Python is a huge dependency, but really, Windows is close to the only OS that doesn't ship with Python or otherwise requires it for most things.

-- 
- Alex

On 03-04-2012 11:06, Iain Buclaw wrote:
> On 3 April 2012 09:23, Andrew Wiley<wiley.andrew.j@gmail.com>  wrote:
>> On Tue, Apr 3, 2012 at 1:37 AM, Alex Rønne Petersen<xtzgzorex@gmail.com>  wrote:
>>> On 03-04-2012 04:35, Andrew Wiley wrote:
>>>>
>>>> On Mon, Apr 2, 2012 at 9:04 PM, Alex Rønne Petersen<xtzgzorex@gmail.com>
>>>>   wrote:
>>>>>
>>>>> On 03-04-2012 01:19, Joseph Rushton Wakeling wrote:
>>>>>
>>>>>>
>>>>>> On 03/04/12 00:48, Alex Rønne Petersen wrote:
>>>>>>>
>>>>>>>
>>>>>>> The Waf meta build system has good support for both GDC and LDC.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm reluctant to use Waf due to the issues described here ... :-(
>>>>>> http://lists.debian.org/debian-devel/2010/02/msg00714.html
>>>>>>
>>>>>
>>>>> Which ones in particular? Debian lacking a system-level Waf doesn't seem
>>>>> like a huge issue to me.
>>>>>
>>>>
>>>> Unless you want someone else to build your software.
>>>
>>>
>>> Include the Waf binary with your software. It's designed to be small so that
>>> you can do this.
>>>
>>>
>>>> My biggest frustration with open source software and specifically with
>>>> meta build systems is that I don't want to learn a scripting language
>>>> or a scripting language's package manager just to build and use a
>>>> piece of software in a completely unrelated language, and if there's
>>>> no pre-packaged version of a build system, I'm not going to take the
>>>> time to figure out how to use whatever package manager language X uses
>>>> to install that build system and all dependencies. Most likely the
>>>> dependencies and build system will wind up in my home directory, which
>>>> is hackish at best, and it'll all sit there forever and clutter up my
>>>> home directory because I'll never touch that package manager again.
>>>> For a build that will be set up exactly once and modified extremely
>>>> rarely after the first month or so, how is this an improvement over
>>>> this Makefile that can already do perfect incremental builds:
>>>>
>>>> TARGET  := someexecutable
>>>> SRCS    := $(shell find -type f -name '*.d')
>>>> OBJS    := ${SRCS:.d=.o}
>>>> DEPS    := ${SRCS:.d=.dep}
>>>> XDEPS   := $(wildcard ${DEPS})
>>>> DC      := gdc
>>>>
>>>> DFLAGS = -Wall -Werror -g -O2
>>>> LDFLAGS =
>>>> LIBS    = -lpthread
>>>>
>>>> .PHONY: all clean distclean
>>>> all:: ${TARGET}
>>>>
>>>> ifneq (${XDEPS},)
>>>> include ${XDEPS}
>>>> endif
>>>>
>>>> ${TARGET}: ${OBJS}
>>>>      ${DC} ${LDFLAGS} ${DFLAGS} -o $@ $^ ${LIBS}
>>>>
>>>> ${OBJS}: %.o: %.d %.dep
>>>>      ${DC} ${DFLAGS} -o $@ -c $<
>>>>
>>>> ${DEPS}: %.dep: %.d
>>>>      ${DC} ${DFLAGS} -fsyntax-only -fmake-mdeps=$@ $<
>>>>      sed -i 's:$(notdir ${<:.d=.o}):${<:.d=.o}:g' $@
>>>>
>>>> clean::
>>>>      -rm -f ${OBJS} ${DEPS} ${TARGET}
>>>>
>>>> distclean:: clean
>>>
>>>
>>> I understand your frustration about having to learn another language.
>>> Learning a language is always an expensive task. But people don't
>>> necessarily know Make syntax, just as they don't necessarily know Python, or
>>> whatever (and I might add that Make can get very frustrating - the
>>> requirement to use hard tabs is extremely annoying and unintuitive).
>>>
>> Either way, you're going to set up your build system once and rarely
>> change it, so the syntax isn't really what bothers me. What matters
>> isn't really the difficulty of setting up the build system, it's the
>> difficulty of going from blank slate to finished binary for someone
>> who has just downloaded the code. For better or worse, systems like
>> make are ubiquitous, whereas with other build systems, I have to go
>> install it. That still isn't too bad if there's a package I can
>> install in the package manager I already use to manage my system, but
>> when the developers actively discourage that convenience, I become
>> concerned.
>>
>>> A problem with systems like Make is that it is hard to keep Makefiles
>>> portable. It doesn't take much to accidentally introduce some sort of
>>> platform/shell/compiler dependency. Python, as a programming language, at
>>> least helps abstract most of these things away (for instance, shell syntax).
>>
>> Thanks to MSYS/MinGW, that Makefile I quoted runs on both Windows and
>> Linux. It depends on find and sed. The dependency on find is easily
>> removed if you're not too lazy to list source files like I am, and the
>> sed dependency can be removed if you don't care too much about perfect
>> incremental builds (there's probably a Windows shell equivalent, I
>> haven't checked).
>> I don't have a Mac, but I wouldn't expect sed/find to be an issue there.
>>
>>> Anyway, as for what 'language' to use, it all comes down to your personal
>>> situation. If you know Python, using something like Waf is completely
>>> inexpensive, just as using Make is inexpensive if you know the Make syntax.
>>
>> I don't know Make syntax and I have no interest in learning it. What
>> you see above was cobbled together once from a variety of online
>> sources, tested thoroughly, and reused abusively because the only
>> thing necessary to use it was to copy it to a new project. No large
>> language installations, no oversized frameworks or tools. It works
>> with most linux distributions out of the box, and on Windows you
>> already have to install GCC (which includes make) to get GDC.
>
> Make is fairly simple.  What makes it the complex beast it is - IMO -
> when used in conjunction with autotools.  :-)
>
>
>

No argument there. It *really* is simple. The problem is that it's so simple that when you start doing advanced stuff, you basically enter shell land where nothing is portable...

-- 
- Alex

Jacob Carlborg, el  3 de abril a las 16:45 me escribiste:
> On 2012-04-03 12:56, Leandro Lucarella wrote:
> >People that don't like Make is people don't understand Make :)
> 
> I do have some understanding of Make. BTW, Rake is basically a Make implementation that uses Ruby for the makefiles, it's _a lot_ better than Make.

Sorry, if you expect Make to be a build system, you don't understand Make :)

Make is only a small part of the picture, is just a dependency tracking program, and a pretty good one if you ask me (but I agree it could be better), to work you have to specify the dependencies (manually or automatically, it's up to you). I don't know Rake but I would be very surprised if it's really better than Make at doing what Make was designed for. *Very surprised*.

Saying that Make is a bad build system is the same as saying an HTML parser is a bad web browser.


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si por el chancho fuera, se autocomería con chimichurri Worshestershire!

My votes on waf.  So I think I'll share my experiences with it.

Several years ago I wanted a cross platform solution to handling project builds.  I had been using eclipse/CodeBlocks which worked OK for simple project but the lack of binary libraries for D and Windows combined made me desire something else.

When I first discovered waf, I recall it being explicitly stated the idea was to have a small binary that lives with the package.  The purpose was that every project could include it and no matter how many Waf releases later it will still compile.  That philosophy sort of goes against the idea of packaging it, as any project that uses it should contain it's own copy.

Over the years I found it does it's job quite well.  I've been using it exclusively for larger D projects and I keep the binary as part of the repository.

Other than it being a python script, which attempts to be platform neutral by design.  My favorite feature is the automatic dependency feature.  Working with Windows, D in particular, means I have to build both the C/C++ library as well as the D glue code.

I find it simple enough, since waf is python, to replicate the build process of other software that I can compile the library and then use the uselib feature to have it used by my final executable.  When dealing with external dependencies, it's even possible to store just the waf build script and download the library source separately.  If you wanted to get fancy you could make waf download it instead.

I've even made it do something crazy like using D compiler specific to it's project for compiling the source.  That was as trivial as doing this at the top of the file.

os.environ["PATH"] = "C:/GDC-Tango/mingw/bin"
os.environ["CPATH"] = "C:/GDC-Tango/mingw/include"


With that said, I do find the lack actual use documentation annoying. It took me about an hour to figure out how the new uselib system worked.  But it seems to be improving.  I tend to copy my own scripts and strip it down to the core commands when I need one.

I'll even include a sample wscript file.  This is what I use when starting a new project with waf.  This is essentially a Makefile and doesn't utilize any of the advanced api.

-- Dummy wscript --
#waf configure
#waf build

import os, sys

top = '.'
out = 'build'

src_files = [
    'src.d',
]

def options(opt):
    # build options go here
    pass

def configure(conf):
    #conf.check_tool('dmd')
    conf.check_tool('gdc')
    conf.check_tool('gcc')

    # Windows support
    if sys.platform == 'win32':
        conf.env.DFLAGS_WIN32       = ['-v2', '-m32', '-fversion=EnableVararg']
        conf.env.LINKFLAGS_WIN32    = ['-v2', '-m32']
        conf.env.LIB_WIN32          = ['user32', 'gdi32']

    if sys.platform == 'linux2':
        conf.env.LIB_LINUX2 = ['dl', 'GL']

def build(bld):
# Search external dir for wscript or wscript_build
#    bld.add_subdirs('subdir')

    example = bld.new_task_gen(
        features        = 'd dprogram',
        source          = ['main.d' + src_files],
        target          = 'example',
        importpaths     = '.',
        # I don't think theirs an equivalent yet.
        #defines        = ['WINDOWS=1'], # Equivalent?
        dflags          = '-fversion=Static -g -v',
        libpaths        = '',
        libs            = '',
        use             = 'libsubdir derelict',
        uselib          = 'TANGO WIN32 LINUX2',
    )

On 2012-04-03 17:20, Leandro Lucarella wrote:
> Jacob Carlborg, el  3 de abril a las 16:45 me escribiste:
>> On 2012-04-03 12:56, Leandro Lucarella wrote:
>>> People that don't like Make is people don't understand Make :)
>>
>> I do have some understanding of Make. BTW, Rake is basically a Make
>> implementation that uses Ruby for the makefiles, it's _a lot_ better
>> than Make.
>
> Sorry, if you expect Make to be a build system, you don't understand
> Make :)
>
> Make is only a small part of the picture, is just a dependency tracking
> program, and a pretty good one if you ask me (but I agree it could be
> better), to work you have to specify the dependencies (manually or
> automatically, it's up to you). I don't know Rake but I would be very
> surprised if it's really better than Make at doing what Make was
> designed for. *Very surprised*.

Ok, let me rephrase that. Rakefiles have a lot better syntax than makefiles.

-- 
/Jacob Carlborg

On 03/04/2012 03:35, Andrew Wiley wrote:
> Unless you want someone else to build your software.
> My biggest frustration with open source software and specifically with
> meta build systems is that I don't want to learn a scripting language

So use D! I use D for my build script, works just fine.

https://github.com/mrmonday/serenity/blob/master/build.d

In ~365 LoC that I hacked together and didn't put much effort in to it builds a library and a binary, prints a coloured status update, supports parallel and remote builds, debug and release builds and a few other things.

Bonuses:
 * You get a full, awesome language to use
 * It's fast and easy
 * It's very maintainable by anyone who's working on your code (since they already know D)

-- 
Robert
http://octarineparrot.com/

On 4/3/12, Robert Clipsham <robert@octarineparrot.com> wrote:
> So use D! I use D for my build script, works just fine.

And for the user it's a simple call to 'rdmd script.d'. No need to install anything. You could even use curl to automatically fetch dependencies.

On 2012-04-03 22:36, Robert Clipsham wrote:
> So use D! I use D for my build script, works just fine.
>
> https://github.com/mrmonday/serenity/blob/master/build.d
>
> In ~365 LoC that I hacked together and didn't put much effort in to it
> builds a library and a binary, prints a coloured status update, supports
> parallel and remote builds, debug and release builds and a few other
> things.
>
> Bonuses:
> * You get a full, awesome language to use
> * It's fast and easy
> * It's very maintainable by anyone who's working on your code (since
> they already know D)
>

But that only works for Posix?

-- 
/Jacob Carlborg

On 03/04/12 04:04, Alex Rønne Petersen wrote:
> On 03-04-2012 01:19, Joseph Rushton Wakeling wrote:
>> On 03/04/12 00:48, Alex Rønne Petersen wrote:
>>> The Waf meta build system has good support for both GDC and LDC.
>>
>> I'm reluctant to use Waf due to the issues described here ... :-(
>> http://lists.debian.org/debian-devel/2010/02/msg00714.html
>>
>
> Which ones in particular? Debian lacking a system-level Waf doesn't seem like a
> huge issue to me.

You could also see: http://lists.debian.org/debian-devel/2012/02/msg00207.html

Put simply, for me it's not about whether Debian has a package or not; I don't want to use a build system that is rejected by one of the largest and most important FOSS distros out there.  I'm also worried by the deliberate efforts to stymie Debian's packaging work -- it's important to me that my dependencies play nice with the rest of the FOSS ecosystem.

I should add that I'm not just looking for a build script -- I'm looking for something that does the equivalent of the full Autotools setup, i.e. checking for dependencies, customizing the build script to the individual user environment etc.

On 04-04-2012 05:09, Joseph Rushton Wakeling wrote:
> On 03/04/12 04:04, Alex Rønne Petersen wrote:
>> On 03-04-2012 01:19, Joseph Rushton Wakeling wrote:
>>> On 03/04/12 00:48, Alex Rønne Petersen wrote:
>>>> The Waf meta build system has good support for both GDC and LDC.
>>>
>>> I'm reluctant to use Waf due to the issues described here ... :-(
>>> http://lists.debian.org/debian-devel/2010/02/msg00714.html
>>>
>>
>> Which ones in particular? Debian lacking a system-level Waf doesn't
>> seem like a
>> huge issue to me.
>
> You could also see:
> http://lists.debian.org/debian-devel/2012/02/msg00207.html
>
> Put simply, for me it's not about whether Debian has a package or not; I
> don't want to use a build system that is rejected by one of the largest
> and most important FOSS distros out there. I'm also worried by the
> deliberate efforts to stymie Debian's packaging work -- it's important
> to me that my dependencies play nice with the rest of the FOSS ecosystem.

What went wrong here is that the Debian guys tried to package something as a system-level package when it isn't supposed to be. I don't really see anything wrong in the Waf dev trying to prevent this; not doing so is letting Debian shoot itself in the foot, only to come back to Waf later and complain, when they were already warned.

So, I just think you should reevaluate what you're basing your decision on here. :)

>
> I should add that I'm not just looking for a build script -- I'm looking
> for something that does the equivalent of the full Autotools setup, i.e.
> checking for dependencies, customizing the build script to the
> individual user environment etc.

(Not sure if you know, but Waf can do all of those.)

-- 
- Alex