OK - just tested it, a couple of notes:
- put dsss.conf in dool/src
- run dsss build

A) should the dsss.conf be put in dool/ rather than dool/src in which case, I guess the dsss.conf file needs changing?

B) it outputs all the .o files into src directory
perhaps the default should be dool/obj/* - replicating the directory
structure (eg. using dmd -p) , just in case two files have the same name

B2) is there an option to write these .o files  to /tmp/.... so that I can build from a readonly filesystem?

C) it creates dool/src/libSSD-dool.a
ideally it should create dool/libdool.a ?

D) is it storing somewhere that it has created libdool.a, and it's location, link dependencies etc. so that when we build leds, it can just say it depends on dool, and automatically finds the location of the .a, and it's -l dependencies

Regards
Alan




Gregor Richards wrote:
> Alan Knowles wrote:
>>> name=dool
>>> [dool]
>>>
>> Is that sufficient to build dool?
> 
> Yeah, that's the dsss.conf in place for building dool right now.
> 
>  - Gregor Richards

Alan Knowles wrote:
> OK - just tested it, a couple of notes:
> - put dsss.conf in dool/src
> - run dsss build
> 
> A) should the dsss.conf be put in dool/ rather than dool/src
> in which case, I guess the dsss.conf file needs changing?

dsss.conf expects to be in the "top level."  You could also put a dsss.conf in dool/ with:

name = dool
[src]
type = subdir

And the "real" dsss.conf in src/:

[dool]

> 
> B) it outputs all the .o files into src directory
> perhaps the default should be dool/obj/* - replicating the directory
> structure (eg. using dmd -p) , just in case two files have the same name

Yeah, it's problematic, and actually comes down partially to a bug in bu[il]d, upon which DSSS is built.  I'll add this to the TODO list.

> 
> B2) is there an option to write these .o files  to /tmp/.... so that I
> can build from a readonly filesystem?

That'd be a nice feature. Also goes on the list.

> 
> C) it creates dool/src/libSSD-dool.a
> ideally it should create dool/libdool.a ?

It generates a name with this information (btw, it's libSDD-dool):

1) S = static, so that the -l options for static and shared can be different.
2) D = it's in D
3) D = using DMD (so that you can have both DMD and GDC installed without them fighting)
4) The rest is the package name.

Furthermore, the name becomes quite unimportant, since anything importing dool using DSSS will automatically get linked against the proper library (that is, you don't need to put any dependency info in other dsss.conf's)

That all being said, you can override it, it just ends up creating more problems than it solves.  You can set:
target = dool

Which will make it: libdool.a | dool.lib

In short: Ideally, no, it should create libSDD-dool, I architected the library naming convention for very specific reasons.

> 
> D) is it storing somewhere that it has created libdool.a, and it's
> location, link dependencies etc. so that when we build leds, it can just
> say it depends on dool, and automatically finds the location of the .a,
> and it's -l dependencies

You don't even have to say it depends on dool in any metaformat, you just have to import dool.whatever in the source.

Furthermore, if you import dool.<whatever> in the source, end users could get dool installed with simply 'dsss net deps'.

> 
> Regards
> Alan
> 
> 
> 
> 
> Gregor Richards wrote:
> 
>>Alan Knowles wrote:
>>
>>>>name=dool
>>>>[dool]
>>>>
>>>
>>>Is that sufficient to build dool?
>>
>>Yeah, that's the dsss.conf in place for building dool right now.
>>
>> - Gregor Richards

Alan Knowles wrote:

> Just to let you know, the intention is to remove all Makefiles from:
> duit
> dool
> dantfw
> leds
> 
> and replace them with build.compd files:
> see:
> http://svn.dsource.org/projects/dool/trunk/README.compd
> 
> example build file: http://svn.dsource.org/projects/dool/trunk/build.compd
> 
> I'm not sure if this impacts on the DSSS installer files for any of
> these projects.

Great, another Make replacement. I'll toss it on my pile. :-P

Think I will just go back to GNU Make, which works already...

And let you guys battle it out. (then send me any wxD patches)

--anders

BCS wrote:
> dsss net install mango
> 
> and get a single line of output
> 
> Synchronizing...

dsdpc@chesed:~$ dsss net install mango
Synchronizing...
+ curl -s -k
http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
dpc@chesed:~$ dsss net install mango
Synchronizing...
+ curl -s -k
http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
dpc@chesed:~$ dsss net install mango
Synchronizing...
+ curl -s -k
http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
dpc@chesed:~$


Manually connecting to svn.dsource.org via http gives connection timeout. Should DSSS by more informative here?

It seems that when making libSDD-$dir.a DSSS archives ".o" files as they are. But what if in top level dir there are fies named same as in $dir subdir?

dpc@chesed:~/tmp/dsss-test1$ dsss build
Creating imports for DD-pkg

pkg => DD-pkg
+ /home/dpc/d/bin/dsss_build -I/home/dpc/d/include/d -LIBPATH=/home/dpc/d/lib -LIBPATH=.  -od. -g -debug -explicit -lib -full
pkg/b.d -TlibSDD-pkg.a
/usr/bin/ar: creating libSDD-pkg.a

a.d => a
+ /home/dpc/d/bin/dsss_build -I/home/dpc/d/include/d -LIBPATH=/home/dpc/d/lib -LIBPATH=.  -od. -g -debug
a.d -Ta
a.o:(.data+0x30): undefined reference to `_ModuleInfo_1b'
a.o: In function `_Dmain':
/home/dpc/tmp/dsss-test1/a.d:4: undefined reference to `_Class_1b1B'
/home/dpc/tmp/dsss-test1/a.d:4: undefined reference to `_D1b1B5_ctorFZC1b1B'
collect2: ld returned 1 exit status


No good.

Am I doing anything wrong? In attachment - test dir. If I'm right that DSSS should use some profix or even compress *.o files in subdirs (is that possible?) to avoid object name conflicts.

Dawid Ciężarkiewicz wrote:
> BCS wrote:
>> dsss net install mango
>>
>> and get a single line of output
>>
>> Synchronizing...
> 
> dsdpc@chesed:~$ dsss net install mango
> Synchronizing...
> + curl -s -k
> http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
> dpc@chesed:~$ dsss net install mango
> Synchronizing...
> + curl -s -k
> http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
> dpc@chesed:~$ dsss net install mango
> Synchronizing...
> + curl -s -k
> http://svn.dsource.org/projects/dsss/sources/source.list -o /home/dpc/d/share/dsss/sources/source.list -z /home/dpc/d/share/dsss/sources/source.list
> dpc@chesed:~$
> 
> 
> Manually connecting to svn.dsource.org via http gives connection timeout.
> Should DSSS by more informative here?

Looks to me like 'curl' should be more informative here :)

I'll see if there's some flag I can give it to make it so.

 - Gregor Richards

Dawid Ciężarkiewicz wrote:
> It seems that when making libSDD-$dir.a DSSS archives ".o" files as they
> are. But what if in top level dir there are fies named same as in $dir
> subdir?
> 
> dpc@chesed:~/tmp/dsss-test1$ dsss build
> Creating imports for DD-pkg
> 
> pkg => DD-pkg
> + /home/dpc/d/bin/dsss_build -I/home/dpc/d/include/d -LIBPATH=/home/dpc/d/lib -LIBPATH=.  -od. -g -debug -explicit -lib -full
> pkg/b.d -TlibSDD-pkg.a
> /usr/bin/ar: creating libSDD-pkg.a
> 
> a.d => a
> + /home/dpc/d/bin/dsss_build -I/home/dpc/d/include/d -LIBPATH=/home/dpc/d/lib -LIBPATH=.  -od. -g -debug
> a.d -Ta
> a.o:(.data+0x30): undefined reference to `_ModuleInfo_1b'
> a.o: In function `_Dmain':
> /home/dpc/tmp/dsss-test1/a.d:4: undefined reference to `_Class_1b1B'
> /home/dpc/tmp/dsss-test1/a.d:4: undefined reference to `_D1b1B5_ctorFZC1b1B'
> collect2: ld returned 1 exit status
> 
> 
> No good.
> 
> Am I doing anything wrong? In attachment - test dir. If I'm right that DSSS
> should use some profix or even compress *.o files in subdirs (is that
> possible?) to avoid object name conflicts.

Yes, it should. It /doesn't/ because no compiler agrees on it :)

It's on the todo list.

 - Gregor Richards

Itsmeagain. (I hope my feedback is appreciated ;-)

$ dsss net install mango
[...]


mango/sys => DD-mango-sys
+ /home/dpc/d/bin/dsss_build -I/home/dpc/d/include/d -LIBPATH=/home/dpc/d/lib -LIBPATH=.  -od.  -explicit -lib -full
mango/sys/ByteSwap.d mango/sys/Epoch.d mango/sys/OS.d mango/sys/System.d
mango/sys/Atomic.d -TlibSDD-mango-sys.a
mango/sys/Epoch.d(337): function std.c.linux.linux.localtime (__time_t*)
does not match parameter types (int*)
mango/sys/Epoch.d(337): Error: cannot implicitly convert expression (& utc)
of type int* to __time_t*


This is probably some bug in mango, but I'm thinking about features in DSSS that would allow me to try older (maybe marked as stable) versions of it. Please think about that.

If "dsss net list" tells the true then:
[...]
dsss
dsss-0.5
dsss-0.6
dsss-0.7
dsss-svn
dsss-test
[...]

is something that I'd like to have. But for -svn even easy switch like:

"dsss net install mango-svn -r -10"

that would try compiling mango ten revisions before trunk, would be superb.

Just an idea. :)