Skip to content
This repository has been archived by the owner on Sep 15, 2022. It is now read-only.

Change targetType from 'sourceLibrary' to the implicit 'library'. #12

Merged
1 commit merged into from Sep 2, 2015
Merged

Change targetType from 'sourceLibrary' to the implicit 'library'. #12

1 commit merged into from Sep 2, 2015

Conversation

p0nce
Copy link

@p0nce p0nce commented Sep 2, 2015

I'm not confident about using sourceLibrary in DUB.
For one, IDE projects generated by DUB for Sublime Text or VisualD don't show the imageformats source files.
Secondly, the advantage of compiling all-at-once are still there with --combined.

…allows to get source files in IDE projects generated by DUB
@sigod
Copy link

sigod commented Sep 2, 2015

Secondly, the advantage of compiling all-at-once are still there with --combined.

Can you provide some links about --combined? For some reason I can't find anything. Is it DUB's switch?

@p0nce
Copy link
Author

p0nce commented Sep 2, 2015

Yes, it is documented on dub run -h, dub build -h or dub generate -h.

dub generate --combined visuald will generate all projects in a single .vcxproj, and similarly for Sublime.

--combined build tends to have more problems when the different packages have flags requirements.
But sourceLibrary would be affected as well. My angst with sourceLibraryis that I don't see many people use it, and I can almost feel the future problems coming our way :)

@sigod
Copy link

sigod commented Sep 2, 2015

Yes, it is documented on dub run -h, dub build -h or dub generate -h.

dub generate --combined visuald will generate all projects in a single .vcxproj, and similarly for Sublime.

Never knew about it. Thanks.

and I can almost feel the future problems coming our way :)

You mean significant compilation time?

@p0nce
Copy link
Author

p0nce commented Sep 2, 2015

No no, build problems. (Compilation time should be better for sourceLibrary and --combined)

For example, let's say I have a compiler codegen bug in LDC 17.0.x. By compiling in separate libraries I can use a DUB variable to disable optimization for this package, and done. But such a work-around doesn't work with --combined and sourceLibrary. They break locality of compile bugs because now any user package is affected. Example of such: AuburnSounds/Dplug#35

Basically I'm advocating for more separate compilation, because using sourceLibrary can reveal annoying because it limits choice for building. And it is very much a problem in my experience, --combined-type builds are easier to break.

ghost pushed a commit that referenced this pull request Sep 2, 2015
Change targetType from 'sourceLibrary' to the implicit 'library'.
@ghost ghost merged commit b8b02a9 into tjhann:master Sep 2, 2015
@p0nce
Copy link
Author

p0nce commented Sep 2, 2015

Thanks.

@sigod
Copy link

sigod commented Sep 2, 2015

Interesting. I need to dig into this. Thanks.

This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants