RejectedSoftware Forums

Sign up

Reduntant recompilations

Hi, i use very heavy library GtkD as library package in my small project. And DUB is compiling GtkD every 'dub build' command, even there is no need in this, thus compilation continues within a minute.

Does dub have any options to prevent such behavior?

P.S. Pull request for GtkD dub package is reviewing at the moment, therefore i use local repository installation (dub add-local).

Re: Reduntant recompilations

On Fri, 04 Oct 2013 11:35:59 GMT, NCrashed wrote:

Hi, i use very heavy library GtkD as library package in my small project. And DUB is compiling GtkD every 'dub build' command, even there is no need in this, thus compilation continues within a minute.

Does dub have any options to prevent such behavior?

P.S. Pull request for GtkD dub package is reviewing at the moment, therefore i use local repository installation (dub add-local).

It's planned to build each package separately, but the schedule for that is not yet clear due to a lack of manpower. However, you can work around it with a little manual modification of GTkD's package.json. Conceptually it would look like this:

{
  "name": "gtkd",
  "importPaths": ["src"],
  "configurations": [
    {
      "name": "library",
      "targetType": "library",
      "sourcePaths": ["src"]
    },
    {
      "name": "prebuiltLibrary",
      "targetType": "sourceLibrary",
      "dflags-posix": ["-L$PACKAGE_DIR", "-lgtkd"],
      "sourceFiles-windows-x86": ["gtkd.lib"]
    }
  ]
}

Then run "dub build" once in the GtkD directory and use "subConfigurations": {"gtkd": "prebuiltLibrary"} in dependent projects.

Disclaimer: I haven't actually tested this. It should work in principle but there may be some wrong details in the draft.

Re: Reduntant recompilations

On Fri, 04 Oct 2013 13:21:13 GMT, Sönke Ludwig wrote:

It's planned to build each package separately, but the schedule for that is not yet clear due to a lack of manpower. However, you can work around it with a little manual modification of GTkD's package.json. Conceptually it would look like this:

{
  "name": "gtkd",
  "importPaths": ["src"],
  "configurations": [
    {
      "name": "library",
      "targetType": "library",
      "sourcePaths": ["src"]
    },
    {
      "name": "prebuiltLibrary",
      "targetType": "sourceLibrary",
      "dflags-posix": ["-L$PACKAGE_DIR", "-lgtkd"],
      "sourceFiles-windows-x86": ["gtkd.lib"]
    }
  ]
}

Then run "dub build" once in the GtkD directory and use "subConfigurations": {"gtkd": "prebuiltLibrary"} in dependent projects.

Disclaimer: I haven't actually tested this. It should work in principle but there may be some wrong details in the draft.

This workaround operates well with projects without subpackages. I realized that subpackages are built into one huge lib file anyway (Is this expected behavior or temporally solution?).

It's planned to build each package separately, but the schedule for that is not yet clear due to a lack of manpower.

The most proper way i found is help you with that issue. Are there any pitfalls to know before forking and creating pull request?

Re: Reduntant recompilations

On Fri, 04 Oct 2013 14:29:37 GMT, NCrashed wrote:

On Fri, 04 Oct 2013 13:21:13 GMT, Sönke Ludwig wrote:

It's planned to build each package separately, but the schedule for that is not yet clear due to a lack of manpower. However, you can work around it with a little manual modification of GTkD's package.json. Conceptually it would look like this:

{
  "name": "gtkd",
  "importPaths": ["src"],
  "configurations": [
    {
      "name": "library",
      "targetType": "library",
      "sourcePaths": ["src"]
    },
    {
      "name": "prebuiltLibrary",
      "targetType": "sourceLibrary",
      "dflags-posix": ["-L$PACKAGE_DIR", "-lgtkd"],
      "sourceFiles-windows-x86": ["gtkd.lib"]
    }
  ]
}

Then run "dub build" once in the GtkD directory and use "subConfigurations": {"gtkd": "prebuiltLibrary"} in dependent projects.

Disclaimer: I haven't actually tested this. It should work in principle but there may be some wrong details in the draft.

This workaround operates well with projects without subpackages. I realized that subpackages are built into one huge lib file anyway (Is this expected behavior or temporally solution?).

It's temporary at best. Sub packages need still need some serious improvements (not much work in practice, mostly just some additional command line options). In the current state they are just really useful for being used as external dependencies and pretty much inaccessible for building/using directly.

It's planned to build each package separately, but the schedule for that is not yet clear due to a lack of manpower.
The most proper way i found is help you with that issue. Are there any pitfalls to know before forking and creating pull request?

I think we should start to build up a rough design draft in the wiki of how everything will fit together, which additional or compatibility options should be available, and how it will interact with future incremental building. Robert Klotzner in particular had a number of ideas and started to push DMD in a direction that will allow proper incremental builds. See also http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/274/#post-288.

Re: Reduntant recompilations

Am 05.10.2013 10:33, schrieb Sönke Ludwig:

I think we should start to build up a rough design draft in the wiki of how everything will fit together, which additional or compatibility options should be available, and how it will interact with future incremental building. Robert Klotzner in particular had a number of ideas and started to push DMD in a direction that will allow proper incremental builds. See also http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/274/#post-288.

Started to write something:
https://github.com/rejectedsoftware/dub/wiki/Separate-compilation-and-caching-of-dependencies