On 30.11.2011 08:15, Jacob Carlborg wrote:
> On 2011-11-29 22:14, torhu wrote:
>>  On 29.11.2011 13:20, Jacob Carlborg wrote:
>>>  On 2011-11-29 12:00, Andrej Mitrovic wrote:
>>>>  FWIW a couple of bugs from the old issue tracker were fixed in the new
>>>>  fork. Bugs were reported here:
>>>>  https://bitbucket.org/h3r3tic/xfbuild/issue/16/xfbuild-crashes-if-full-path-to-deps-objs
>>>>
>>>>  https://bitbucket.org/h3r3tic/xfbuild/issue/17/xfbuild-crashes-optlink-on-windows-if-o
>>>>
>>>>
>>>>  There was also a multithreaded bug that manifested itself on Windows
>>>>  where printing to the console would be interleaved and left the
>>>>  message scrambled. This is now fixed.
>>>>
>>>>  Also, the +xpath option was added, first discussed here:
>>>>  https://bitbucket.org/h3r3tic/xfbuild/issue/1/add-a-xpath-option
>>>>
>>>>  I'll have to look into the whole template instantiation "fiasco" and
>>>>  see where we are at that and if it can be resolved. Stay tuned.. :)
>>>>
>>>>  https://github.com/AndrejMitrovic/xfbuild
>>>
>>>  Walter mentioned something that if the "-lib" flag is used it will
>>>  output templates to all object files. If that was what you were
>>>  referring to.
>>>
>>
>>  The -lib flag leads to bloated executables. Maybe the linker doesn't get
>>  rid of the duplicates, I don't know.
>
> That may be so, but at least the application works, if Walter is correct
> about the -lib flag. He has also said he doesn't want to add a flag that
> does what's necessary with the templates.
>

Maybe this is about something else than I was thinking of.  I was thinking of the linker errors you will get if you do partial rebuilds. Missing symbols for struct initializers and things like that.  And templates too, I guess.  Can't remember the details anymore.  But the -lib flags wouldn't help with that anyway.

Hi,

I'm trying to get xfbuild working.

First I found with WindowsAPI the line 70 of directx\d3d9.d has an error. But fixing it I run into another problem:

Cannot use win32.winsock without Win32_Winsock1 defined.
winsock.d(31): Error: static assert  (false) is false

I'm not sure where dcollections fits in.

Maybe I should just try again will further updates.

Thanks for any help,

-joelcnz

I knew I should have just distributed win32 with xfbuild. Someone screwed up the API headers.

I'll distribute the API with xfbuild in a few minutes. Thanks for letting me know about this.

Or maybe I just cut off the directx stuff. Heh, maybe I'm to blame. Anyway I'll fix this shortly.

Ok it should work now.

On 2011-11-30 21:13, torhu wrote:
> Maybe this is about something else than I was thinking of. I was
> thinking of the linker errors you will get if you do partial rebuilds.
> Missing symbols for struct initializers and things like that. And
> templates too, I guess. Can't remember the details anymore. But the -lib
> flags wouldn't help with that anyway.

I think I'm referring to the same, or something similar. Apparently DMD doesn't emit template instances to all object files that need them. When doing incremental builds it can happen that some of the template instances gets removed when an object file is replaced.

https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental

This link suggests that the -lib flag will put each output the template instances to all object files that need it: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=96168

-- 
/Jacob Carlborg

On 01-Dec-11 2:28 PM, Andrej Mitrovic wrote:
> Ok it should work now.

Thanks Andrej. Works now. Or, I have to change how StopWatch (std.datetime) works in my programs, because putting '*.start;' twice fails an assert.

Also, it doesn't seem to work with Visual D.

One of my programs uses it in the command prompt now. :-)

-joelcnz

On 12/1/11, Joel Christensen <joelcnz@gmail.com> wrote:
> Thanks Andrej. Works now. Or, I have to change how StopWatch (std.datetime) works in my programs, because putting '*.start;' twice fails an assert.

Hmm, I'm not sure what you're referring to. Is something broken about the profiler in xfBuild (it uses stopwatch), or are you referring to your own code?

> Also, it doesn't seem to work with Visual D.

I haven't tested it with VisualD, but I'll give it some testing. VisualD does have it's own builder, of course. How are you invoking it / what exactly is failing?

> One of my programs uses it in the command prompt now. :-)

Cool. If there are any issues (and I know of some where xfBuild likes to crash, some parts need to be refactored), feel free to file them so I can fix them as soon as possible.

On 01-Dec-11 11:08 PM, Andrej Mitrovic wrote:
> On 12/1/11, Joel Christensen<joelcnz@gmail.com>  wrote:
>> Thanks Andrej. Works now. Or, I have to change how StopWatch
>> (std.datetime) works in my programs, because putting '*.start;' twice
>> fails an assert.
>
> Hmm, I'm not sure what you're referring to. Is something broken about
> the profiler in xfBuild (it uses stopwatch), or are you referring to
> your own code?

My own code. I used '*.reset' instead of putting '*.start' in again.

>> Also, it doesn't seem to work with Visual D.
>
> I haven't tested it with VisualD, but I'll give it some testing.
> VisualD does have it's own builder, of course. How are you invoking it
> / what exactly is failing?

VisualD has more than one source file in the compiler arguments.

>> One of my programs uses it in the command prompt now. :-)
>
> Cool. If there are any issues (and I know of some where xfBuild likes
> to crash, some parts need to be refactored), feel free to file them so
> I can fix them as soon as possible.

It doesn't handle deprecated stuff, (at lest without the '-d', but I haven't tried that).

On 01.12.2011 21:07, Joel Christensen wrote:
> On 01-Dec-11 11:08 PM, Andrej Mitrovic wrote:
>> On 12/1/11, Joel Christensen<joelcnz@gmail.com> wrote:
>>> Thanks Andrej. Works now. Or, I have to change how StopWatch
>>> (std.datetime) works in my programs, because putting '*.start;' twice
>>> fails an assert.
>>
>> Hmm, I'm not sure what you're referring to. Is something broken about
>> the profiler in xfBuild (it uses stopwatch), or are you referring to
>> your own code?
>
> My own code. I used '*.reset' instead of putting '*.start' in again.
>
>>> Also, it doesn't seem to work with Visual D.
>>
>> I haven't tested it with VisualD, but I'll give it some testing.
>> VisualD does have it's own builder, of course. How are you invoking it
>> / what exactly is failing?
>
> VisualD has more than one source file in the compiler arguments.
>

You could set the "Build tool" for all files but the main module to "None", so they will not be placed on the command line (doing it on a multi selection does not seem to work, though).

If I understand correctly, xfbuilds' big feature is to collect imported modules and only compile files that are modified or that import modified files, but in a single compiler run. These are linked together afterwards with the remaining object files.

I have considered adding such a compilation mode to Visual D aswell, but I don't see a large advantage to compiling the whole project because the import dependencies easily spread across all files like a virus. Even creating di interface files does not help, as you must not remove imports because it can ruin the order static constructors are run.

If there are natural independent groups of modules, I put them into libraries anyway - otherwise the compiler can run into memory trouble.

What's your experience? Does xfbuild work significantly faster than building all the modules like rdmd?