On 02/02/2015 09:09 AM, Vladimir Panteleev wrote:
Change my view.
Most important point for dub, there is central registry that enables the
http://en.wikipedia.org/wiki/Network_effect.
I definitely agree this is a good thing, but I have yet to see
a good
build system with serious traction that is purely statically
typed and
compiled. Maybe D could be different. Perhaps another GSoC 2015
project
in here?
I haven't tried Shake, but since it's in Haskell...
Atila
It looks like the core issue is that we simply have different goals in
mind. When we were deciding on how the build description works back
then, we basically had these:
- The build description can be reasoned about in a generic way (not
generally possible with an imperative scripting
On Monday, 9 February 2015 at 17:43:58 UTC, Andrei Alexandrescu
wrote:
On 2/9/15 12:43 AM, Russel Winder via Digitalmars-d wrote:
clip
I definitely agree this is a good thing, but I have yet to see
a good
build system with serious traction that is purely statically
typed and
compiled. Maybe
On Monday, 9 February 2015 at 07:15:23 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg
wrote:
The above command will obviously not compile bar.d. What I
mean is that it's no longer enough to pass a single file and
let RDMD track the dependencies.
OK,
On 2015-02-09 08:15, Vladimir Panteleev wrote:
OK, but the obviously trivial fix is to either import bar, or create a
module that imports all other modules in the library. It's not really
enough justification for switching build tools, is it?
I thought the whole point of this thread was that
On 2015-02-09 08:15, Vladimir Panteleev wrote:
OK, but the obviously trivial fix is to either import bar, or create a
module that imports all other modules in the library. It's not really
enough justification for switching build tools, is it?
Setting up dependencies between modules just to
On Monday, 9 February 2015 at 08:16:24 UTC, Jacob Carlborg wrote:
On 2015-02-09 08:15, Vladimir Panteleev wrote:
OK, but the obviously trivial fix is to either import bar, or
create a
module that imports all other modules in the library. It's not
really
enough justification for switching
On Sun, 2015-02-08 at 20:54 +0100, Jacob Carlborg via Digitalmars-d
wrote:
[…]
Since Rake will give you the full power of Ruby I assume you mean some
high level helper constructs?
The Rake community were not really interested in supporting C and C++
builds, let alone LaTeX, with abstractions
On Monday, 9 February 2015 at 08:08:36 UTC, Dicebot wrote:
On Monday, 9 February 2015 at 07:15:23 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg
wrote:
The above command will obviously not compile bar.d. What I
mean is that it's no longer enough to
On Monday, 9 February 2015 at 08:10:56 UTC, Jacob Carlborg wrote:
On 2015-02-09 08:15, Vladimir Panteleev wrote:
OK, but the obviously trivial fix is to either import bar, or
create a
module that imports all other modules in the library. It's not
really
enough justification for switching
On Sunday, 8 February 2015 at 20:34:19 UTC, Jacob Carlborg wrote:
On 2015-02-03 22:02, H. S. Teoh via Digitalmars-d wrote:
Second generation build algorithms are centered around *not*
scanning,
but taking advantage of modern OSes providing APIs for file
change
notification. Rather than scan
On Sun, 2015-02-08 at 08:57 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
* One more language for the maintainers to know and use.
On the other hand by replacing Make you lose two languages, so total one
less language to know.
* One more dependency. Although scripting languages are
On 2/9/15 12:43 AM, Russel Winder via Digitalmars-d wrote:
On Sun, 2015-02-08 at 08:57 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
* One more language for the maintainers to know and use.
On the other hand by replacing Make you lose two languages, so total one
less language to
They are MakefileForD
https://github.com/bioinfornatics/MakefileForD
It is easy to use. You have only to set First lines:
export PROJECT_NAME =
export AUTHOR =
export DESCRIPTION =
export VERSION=
export LICENSE=
ROOT_SOURCE_DIR =
EXE_NAME =
and that will find automatically
Am 07.02.2015 um 15:46 schrieb Jacob Carlborg:
On 2015-02-05 15:11, Sönke Ludwig wrote:
There is a request to make this configurable and it's a rather trivial
addition. I just don't have the time to implement all feature requests
myself, which is basically why it is not implemented, yet.
Is
On 2015-02-08 01:39, Mike Parker wrote:
But apparently this can be done now with dub.selections.json.
Yes, exactly. I just replied to someone calming updating packages
automatically was a good idea. I also had to fight quite a lot to get
this feature into Dub.
--
/Jacob Carlborg
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala builds, and created what has become SBT.
On Sunday, 8 February 2015 at 10:39:22 UTC, Jacob Carlborg wrote:
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem
at hand.
Yes, sorry, sourcePaths and importPaths were the fields I
was thinking about. Although I think
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem at hand.
Yes, sorry, sourcePaths and importPaths were the fields I was
thinking about. Although I think mainSourceFile may be needed as well,
otherwise dub will look for app.d.
--
On 2015-02-06 12:37, Dicebot wrote:
D is only cross-platfrom scripting language we can rely on. This is
probably biggest problem of make (apart from bunch of legacy syntax
crap) - any real build system needs relatively complicated build rules
for target transformation. However we can reasonably
On 2/8/15 3:00 AM, Jacob Carlborg wrote:
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala
On Sun, 2015-02-08 at 12:00 +0100, Jacob Carlborg via Digitalmars-d wrote:
[…]
It's kind of the same in the D community. Before Dub existed I
started to work on both a package manager (Orbit) and a build tool
(never officially announced). I used Ruby as the description format
for package
On 2015-02-08 at 14:59, Russel Winder via Digitalmars-d wrote:
Well clearly it should be rejected, you have to s/Ruby/Python/ ;-)
LOL
As far as I can tell Rake remain the de facto standard tool
in the Ruby community and absolutely nowhere else.
That's by design. A rake gathers hay towards
On 2015-02-05 09:56, Atila Neves wrote:
It depends on how you define out of the box, I guess.
I define it as what's included in a newly installed operating system.
The biggest issue here is Windows vs Posix.
--
/Jacob Carlborg
On 2015-02-08 17:57, Andrei Alexandrescu wrote:
Ehm. This part sounds unnecessarily a bit political - NIH syndrome,
closemindedness of the D folks toward using anything else but D and
make, and such.
I'm just sharing my experience since I've tried this before. I would not
recommend using any
On 2015-02-03 22:02, H. S. Teoh via Digitalmars-d wrote:
Second generation build algorithms are centered around *not* scanning,
but taking advantage of modern OSes providing APIs for file change
notification. Rather than scan the whole source tree every time, it
takes the changeset as input --
On Sunday, 8 February 2015 at 17:59:56 UTC, Jacob Carlborg wrote:
On 2015-02-06 12:37, Dicebot wrote:
D is only cross-platfrom scripting language we can rely on.
This is
probably biggest problem of make (apart from bunch of legacy
syntax
crap) - any real build system needs relatively
On 2015-02-08 14:59, Russel Winder via Digitalmars-d wrote:
I worked on Rant for a while because Rake is not up to building C and
C++ systems due to lack of abstractions. As far as I can tell Rake
remain the de facto standard tool in the Ruby community and absolutely
nowhere else.
Since Rake
On 2015-02-08 12:06, Vladimir Panteleev wrote:
Neither of these will help in resolving the module path and filesystem
path inconsistency, while maintaining compatibility with the git
submodule approach.
I'm not exactly sure what you're looking for but with these fields you
can configure the
On 2015-02-04 19:07, Vladimir Panteleev wrote:
You mean via extern(C)?
You can use pragma(lib), and the compiler will emit a linker instruction
to add the specified library. I'm not sure about the platform support,
though.
No, I mean like this:
module mylib.foo;
void foo () {}
module
On Sunday, 8 February 2015 at 19:52:26 UTC, Jacob Carlborg wrote:
On 2015-02-08 12:06, Vladimir Panteleev wrote:
Neither of these will help in resolving the module path and
filesystem
path inconsistency, while maintaining compatibility with the
git
submodule approach.
I'm not exactly sure
On Sunday, 8 February 2015 at 21:02:14 UTC, Jacob Carlborg wrote:
The above command will obviously not compile bar.d. What I
mean is that it's no longer enough to pass a single file and
let RDMD track the dependencies.
OK, but the obviously trivial fix is to either import bar, or
create a
On 2015-02-05 05:43, Vladimir Panteleev wrote:
Is it a default if you can't change it? Or can it be changed?
It can be changed. It's the mainSourceFile field [1].
It is not a question of preference, it is a question of the behavior
being incompatible with certain tools and workflows.
Sure
On 2015-02-04 23:00, Mike Parker wrote:
Then you specify a specific version of the library as a dependency,
rather than a version range.
No, this is not enough. The tool need to automatically track and lock
the whole dependency graph. Example:
Project A:
dependencies: {
b: 1.0.0
}
On 2015-02-05 15:11, Sönke Ludwig wrote:
There is a request to make this configurable and it's a rather trivial
addition. I just don't have the time to implement all feature requests
myself, which is basically why it is not implemented, yet.
Is the reason for putting it in the home directory
On Saturday, 7 February 2015 at 14:36:19 UTC, Jacob Carlborg
wrote:
On 2015-02-05 05:43, Vladimir Panteleev wrote:
Is it a default if you can't change it? Or can it be changed?
It can be changed. It's the mainSourceFile field [1].
I don't see how this setting is at all relevant to the
On 2/7/2015 11:43 PM, Jacob Carlborg wrote:
On 2015-02-04 23:00, Mike Parker wrote:
Then you specify a specific version of the library as a dependency,
rather than a version range.
No, this is not enough. The tool need to automatically track and lock
the whole dependency graph. Example:
On Thursday, 5 February 2015 at 09:00:05 UTC, Atila Neves wrote:
On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
After reading this thread I think I'm the only person here who
actually likes makefiles.
Nothing ever feels as complete as a good old hand written
makefile.
On Thu, 05 Feb 2015 16:52:53 +0100, Sönke Ludwig wrote:
alas, without this feature dub is not a build system. i understand that
there are alot of things to do and the resources are limited. that's
why i think that dub should be separated to two projects: package
manager and build system.
I believe only truly practical approach is to design a D build
tool as a library (and, ideally, make it a Phobos module). But at
the same time it is important to keep it generic and not tied to
D or building application in general.
There are two important bits here (important for me):
1)
It
On Thu, 2015-02-05 at 16:52 +0100, Sönke Ludwig via Digitalmars-d wrote:
[…]
GIT master now supports generating VisualD, CMake and Sublime Text
project files. Make is also a commonly requested one that would be
easy to add, but hasn't been done yet. Of course it also supports
RDMD using
On Thu, 05 Feb 2015 18:12:56 +0100, Sönke Ludwig wrote:
so i'll use make for everything else too. make can be wordy, but at
least i'll have only one build tool to care about, not two.
If you just want to have a build tool, that's fine (if you want to do
all the dependency tracking and
On Thu, 2015-02-05 at 18:01 +0100, Sönke Ludwig via Digitalmars-d wrote:
[…]
I'm now just left wondering what it is that is fundamentally
flawed. Everything mentioned so far is either
bugs or missing functionality, or rather just mostly missing
convenience.
The core problem is the use of
On Friday, 6 February 2015 at 13:35:43 UTC, Atila Neves wrote:
There are two important bits here (important for me):
The approach I'm thinking of agrees 100% with your two
important bits.
Anything that does not allow me to express such dependency
chain in native straightforward manner
On Fri, 2015-02-06 at 13:35 +, Atila Neves via Digitalmars-d wrote:
[…]
Which is why that's the language I want to express the build in.
Methinks I have some code to write and some emailing to do with
Soenke.
In this situation it would be good having many people working the same
On Friday, 6 February 2015 at 12:30:45 UTC, Daniel Murphy wrote:
Dicebot wrote in message
news:listanyegqyanevsn...@forum.dlang.org...
D is only cross-platfrom scripting language we can rely on.
This is probably biggest problem of make (apart from bunch of
legacy syntax crap) - any real
There are two important bits here (important for me):
The approach I'm thinking of agrees 100% with your two important
bits.
Anything that does not allow me to express such dependency
chain in native straightforward manner without resorting to
external scripts is simply not good enough.
+1 to all of this. Except for the part about CMake relying on
Make. It doesn't, Make is just one of the backends. I haven't
used CMake with anything other than Ninja in a very long time.
Atila
On Friday, 6 February 2015 at 11:04:59 UTC, Russel Winder wrote:
On Thu, 2015-02-05 at 18:01 +0100,
On Friday, 6 February 2015 at 12:30:45 UTC, Daniel Murphy wrote:
Dicebot wrote in message
news:listanyegqyanevsn...@forum.dlang.org...
D is only cross-platfrom scripting language we can rely on.
This is probably biggest problem of make (apart from bunch of
legacy syntax crap) - any real
Dicebot wrote in message news:listanyegqyanevsn...@forum.dlang.org...
D is only cross-platfrom scripting language we can rely on. This
is probably biggest problem of make (apart from bunch of legacy
syntax crap) - any real build system needs relatively complicated
build rules for target
On 5 February 2015 at 07:20, Paulo Pinto via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
After reading this thread I think I'm the only person here who actually
likes makefiles.
Nothing ever feels as complete as a good old
Am 02.02.2015 um 12:00 schrieb Manu via Digitalmars-d:
On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
[snip]
I agree with basically everything you said.
I'll add, I have no
On Thursday, 5 February 2015 at 09:46:44 UTC, Daniel Murphy wrote:
Atila Neves wrote in message
news:wpryuzyjmcdjtocqg...@forum.dlang.org...
I'm don't mind makefiles. That says, our
dmd/druntime/phobos/dlang.org makefiles break at the drop of
a hat. It's also rather difficult to review
Am 04.02.2015 um 23:00 schrieb Mike Parker:
On 2/5/2015 4:02 AM, Jacob Carlborg wrote:
On 2015-02-02 09:58, Joseph Rushton Wakeling via Digitalmars-d wrote:
Scenario: a dependency has a security hole that gets patched. If the
dub package is updated, all applications using that dub package
Atila Neves wrote in message news:myzbnoipafejrpzdw...@forum.dlang.org...
I understand why dependencies are to be avoided. The good thing about the
state of things right now is that one needs only a C++ compiler and make.
That's a good thing.
It certainly is. We are however planning to
Am 03.02.2015 um 21:08 schrieb ketmar:
On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
On 02/03/2015 09:51 AM, ketmar wrote:
'cause it really sux as a build tool.
Not getting into any of the lengthy discussions of yours, but 'it sux'
isn't really helping anyone to improve it.
Am 02.02.2015 um 10:44 schrieb Andrej Mitrovic:
On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote:
snip
Also:
- Dub installs everything in ~/ (home, which on Windows is an awful
location anywho). It's a pain in the ass for browsing dependencies in
your editor. If it's just
Am 02.02.2015 um 15:45 schrieb ketmar:
On Mon, 02 Feb 2015 14:36:00 +, Mathias LANG wrote:
I couldn't disagree more, but I understand how frustrating dub can be. I
also had to adapt my workflow to it.
and sometimes it's plain unusable. it insists on batch builds, and i have
three or so
Am 02.02.2015 um 15:59 schrieb ketmar:
On Mon, 02 Feb 2015 14:18:47 +, Tobias Pankrath wrote:
At least I don't expect Dub to support every single language out there
natively.
that's why other build tools allows to manually specify dependencies and
commands as a last resort. but dub
On Thu, 05 Feb 2015 14:48:12 +0100, Sönke Ludwig wrote:
Am 03.02.2015 um 21:08 schrieb ketmar:
On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
On 02/03/2015 09:51 AM, ketmar wrote:
'cause it really sux as a build tool.
Not getting into any of the lengthy discussions of yours, but
Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
1. rdmd
BTW, there is one thing about RDMD that can be a real issue and one that
is not easily solved without integrating its functionality directly into
DMD: It doesn't track
Am 02.02.2015 um 23:15 schrieb Nick Sabalausky:
On 02/02/2015 03:09 AM, Vladimir Panteleev wrote:
1a. rdmd and D's module system:
[...]
In contrast, Dub's default modus operandi is to blindly send to the
compiler all *.d files found in the src folder, whether they're
actually used or not. Not
On Thu, 05 Feb 2015 15:33:51 +, Mathias LANG wrote:
On Thursday, 5 February 2015 at 15:26:23 UTC, ketmar wrote:
On Thu, 05 Feb 2015 15:21:08 +, Atila Neves wrote:
the package manager part should have good machine interface to
allow it's usage in various scripts and other build
Am 05.02.2015 um 16:18 schrieb ketmar:
On Thu, 05 Feb 2015 16:05:11 +0100, Sönke Ludwig wrote:
Yes, incremental building is indeed a missing feature. It's simply a
matter of available developer time, as for many of the other concerns.
Otherwise this is something that has been acknowledged for
On Thursday, 5 February 2015 at 15:46:57 UTC, Sönke Ludwig wrote:
Am 03.02.2015 um 09:51 schrieb ketmar:
On Tue, 03 Feb 2015 02:19:55 +, Martin Nowak wrote:
There seems to be a general scepticism against dub and I
wonder what the
reasons are.
'cause it really sux as a build tool.
Am 03.02.2015 um 09:51 schrieb ketmar:
On Tue, 03 Feb 2015 02:19:55 +, Martin Nowak wrote:
There seems to be a general scepticism against dub and I wonder what the
reasons are.
'cause it really sux as a build tool.
Just to state the design perspective for a little bit of rationale:
On 2 February 2015 at 22:15, Nick Sabalausky via Digitalmars-d
There's also one other big thing I don't like about it: It needlessly
reinvents and renames dmd's entire set of command switches. That isn't even
needed for ldc/gdc anyway since, last I heard, the ldmd and gdmd wrappers
exist.
On Wednesday, 4 February 2015 at 19:15:16 UTC, Jacob Carlborg
wrote:
On 2015-02-02 09:09, Vladimir Panteleev wrote:
Even if I had faith that dub was a perfectly polished piece of
software,
it doesn't solve any problems I have with building D programs,
and in
fact would make said task more
On Thursday, 5 February 2015 at 07:13:44 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 10:46 PM, weaselcat wrote:
After reading this thread I think I'm the only person here who
actually
likes makefiles.
Nothing ever feels as complete as a good old hand written
makefile.
I'm don't mind
On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote:
After reading this thread I think I'm the only person here who
actually likes makefiles.
Nothing ever feels as complete as a good old hand written
makefile.
Assuming you get it right. In my experience, this is analogous to
Am 05.02.2015 um 15:56 schrieb ketmar:
On Thu, 05 Feb 2015 15:51:23 +0100, Sönke Ludwig wrote:
Am 02.02.2015 um 15:59 schrieb ketmar:
On Mon, 02 Feb 2015 14:18:47 +, Tobias Pankrath wrote:
At least I don't expect Dub to support every single language out there
natively.
that's why
Am 02.02.2015 um 16:34 schrieb Vladimir Panteleev:
On Monday, 2 February 2015 at 14:35:03 UTC, John Colvin wrote:
a little script that calls `dub describe`, extracts the import paths
and then calls dmd -o- appropriately would be easy to do. There's no
fundamental blocker here.
As long as the
On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy
wrote:
1. rdmd
BTW, there is one thing about RDMD that can be a real issue and
one that is not easily solved
On Thursday, 5 February 2015 at 15:14:53 UTC, Sönke Ludwig wrote:
BTW, for what it's worth, you can also do this:
DFLAGS=-o- dub build
It will recognize the -o- and automatically skip the linker
stage, too. But of course that doesn't make it automatically
track dependencies.
Nice! Then all
The approach taken for DUB is to put as much knowledge of the
target problem into the build tool as possible, so that the
amount of work/knowledge required by the developer is minimal
(as long as problem is within the target domain). Make's
approach is the opposite and requires the developer
On Thursday, 5 February 2015 at 14:48:24 UTC, Sönke Ludwig wrote:
- restructure the directory layout of my library (breaking
change)
Not true. Use sourcePaths and importPaths to configure the
package as appropriate.
Right now this is necessary to maintain directory/package path
consistency.
On Thu, 05 Feb 2015 16:05:11 +0100, Sönke Ludwig wrote:
Yes, incremental building is indeed a missing feature. It's simply a
matter of available developer time, as for many of the other concerns.
Otherwise this is something that has been acknowledged for inclusion
basically since the
On Thursday, 5 February 2015 at 15:01:48 UTC, ketmar wrote:
??? i didn't modified mymod.d! why it is rebuilding it?!
'cmon, it's in
no way better than a simple shell script that just executes
dmd -c for
each file and then links the results.
Looks like you missing one of my mails:
On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
BTW, there is one thing about RDMD that can be a real issue and
one that is not easily solved without integrating its
functionality directly into DMD: It doesn't track local and
string imports. This is the main reason why I
there is too much noise there. and there is no easy access to
package
manager itself. as far as i can see, there is no command even
to list all
*known* packages, only installed ones.
You don't need to know all packages, only the ones required by
the build and where they are. For a build
On Thursday, 5 February 2015 at 15:26:23 UTC, ketmar wrote:
On Thu, 05 Feb 2015 15:21:08 +, Atila Neves wrote:
the package manager part should have good machine interface
to allow
it's usage in various scripts and other build systems. and
build
system... oh, well, it can simply use
On Thu, 05 Feb 2015 15:21:08 +, Atila Neves wrote:
the package manager part should have good machine interface to allow
it's usage in various scripts and other build systems. and build
system... oh, well, it can simply use package manager. this way we can
discuss dub-pkg and dub-build as
Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
Even if I had faith that dub was a perfectly polished piece of software,
it doesn't solve any problems I have with building D programs, and in
fact would make said task more complicated. Here's why.
(...)
I think I've already answered most of
On Thu, 05 Feb 2015 15:11:50 +0100, Sönke Ludwig wrote:
Am 02.02.2015 um 15:45 schrieb ketmar:
On Mon, 02 Feb 2015 14:36:00 +, Mathias LANG wrote:
I couldn't disagree more, but I understand how frustrating dub can be.
I also had to adapt my workflow to it.
and sometimes it's plain
the package manager part should have good machine interface
to allow
it's usage in various scripts and other build systems. and build
system... oh, well, it can simply use package manager. this way
we can
discuss dub-pkg and dub-build as separate entities, and
flaws of one
project will not
On Thu, 05 Feb 2015 15:51:23 +0100, Sönke Ludwig wrote:
Am 02.02.2015 um 15:59 schrieb ketmar:
On Mon, 02 Feb 2015 14:18:47 +, Tobias Pankrath wrote:
At least I don't expect Dub to support every single language out there
natively.
that's why other build tools allows to manually
Am 05.02.2015 um 16:01 schrieb ketmar:
On Thu, 05 Feb 2015 14:48:12 +0100, Sönke Ludwig wrote:
Am 03.02.2015 um 21:08 schrieb ketmar:
On Tue, 03 Feb 2015 19:43:53 +0100, Martin Nowak wrote:
On 02/03/2015 09:51 AM, ketmar wrote:
'cause it really sux as a build tool.
Not getting into any
On Thu, 05 Feb 2015 15:17:44 +, Mathias LANG wrote:
On Thursday, 5 February 2015 at 15:01:48 UTC, ketmar wrote:
??? i didn't modified mymod.d! why it is rebuilding it?! 'cmon, it's
in no way better than a simple shell script that just executes dmd -c
for each file and then links the
On Thursday, 5 February 2015 at 15:15:10 UTC, Atila Neves wrote:
The approach taken for DUB is to put as much knowledge of the
target problem into the build tool as possible, so that the
amount of work/knowledge required by the developer is minimal
(as long as problem is within the target
On Thu, 05 Feb 2015 16:12:51 +0100, Sönke Ludwig wrote:
Such as preBuildCommands [1]?
[1]: http://code.dlang.org/package-format#build-settings
nope. such as 'a' depends of 'b', 'b' depends of c, here are commands
to generate 'a' and 'b', don't call that commands if it's not
necessary.
On Thu, 05 Feb 2015 15:34:06 +, Atila Neves wrote:
there is too much noise there. and there is no easy access to package
manager itself. as far as i can see, there is no command even to list
all *known* packages, only installed ones.
You don't need to know all packages, only the ones
BTW, CMake output support (using dub generate cmake) has
recently been added to GIT master.
Very nice!
On Thursday, 5 February 2015 at 16:32:26 UTC, Sönke Ludwig wrote:
I think the only build script I had to write was for RABCDAsm,
which
probably can't be reimplemented as a dub.json file:
http://forum.dlang.org/post/peurhbfebwdskcbal...@forum.dlang.org
Okay, things like testing for DMD bugs
Am 05.02.2015 um 16:35 schrieb ketmar:
On Thu, 05 Feb 2015 16:12:51 +0100, Sönke Ludwig wrote:
Such as preBuildCommands [1]?
[1]: http://code.dlang.org/package-format#build-settings
nope. such as 'a' depends of 'b', 'b' depends of c, here are commands
to generate 'a' and 'b', don't call
Am 05.02.2015 um 16:51 schrieb Atila Neves:
On Thursday, 5 February 2015 at 15:46:57 UTC, Sönke Ludwig wrote:
Am 03.02.2015 um 09:51 schrieb ketmar:
On Tue, 03 Feb 2015 02:19:55 +, Martin Nowak wrote:
There seems to be a general scepticism against dub and I wonder what
the
reasons are.
On 2/5/15 7:15 AM, Atila Neves wrote:
The approach taken for DUB is to put as much knowledge of the target
problem into the build tool as possible, so that the amount of
work/knowledge required by the developer is minimal (as long as
problem is within the target domain). Make's approach is the
Am 05.02.2015 um 16:16 schrieb Vladimir Panteleev:
On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
BTW, there is one thing about RDMD that can be a real issue and one
that is not easily solved without integrating its functionality
directly into DMD: It doesn't track local and
Am 05.02.2015 um 16:15 schrieb Vladimir Panteleev:
On Thursday, 5 February 2015 at 14:48:24 UTC, Sönke Ludwig wrote:
- restructure the directory layout of my library (breaking change)
Not true. Use sourcePaths and importPaths to configure the package
as appropriate.
Right now this is
Am 05.02.2015 um 16:12 schrieb Atila Neves:
On Thursday, 5 February 2015 at 15:01:57 UTC, Sönke Ludwig wrote:
Am 02.02.2015 um 09:09 schrieb Vladimir Panteleev:
On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
1. rdmd
BTW, there is one thing about RDMD that can be a real
1 - 100 of 240 matches
Mail list logo
