RejectedSoftware Forums

Sign up

Pages: 1 2

Re: Template-heavy code and DUB

avatar
Sönke Ludwig
Posted Mon, 21 Oct 2013 11:42:55 GMT in reply to Joseph Rushton Wakeling
Reply

Am 21.10.2013 13:07, schrieb Joseph Rushton Wakeling:> (...)

dub build dgraph:whatever works to build any of the executables, and downstream projects seem to interact fine with dgraph as a sourceLibrary. The one thing I'd like to have is some way to build all of the executables at once -- dub build dgraph:util or something like that; I tried creating a subpackage with "targetType": "none" with dependencies on all of them, but dub rejected that as "none" implied, nothing to build.

There is issue #97 still open, which should make this approach work.

Something like "dub build --recursive" could be another possibility for such situations, I didn't fully think this through, yet.

I didn't quite follow your proposal to have a separate package.json in each of the different executables' project directories -- how would this work from a dub build perspective?

The complete outline would be: 

/
  package.json        {"name": "dgraph", "targetType": "sourceLibrary"}
  import/
    dgraph/
      graph.d
      metric.d
  tests/
    graphtest/
      source/
        graphtest.d
      package.json    {"name": "graphtest", "dependencies": {
                         "dgraph": {"version": "~master", "path": "../../"}
                      }}
    betweenness50/
      source/
        betweenness50.d
      package.json    {"name": "betweenness50", "dependencies": {
                         "dgraph": {"version": "~master", "path": "../../"}
                      }}

Building then works simply using "cd tests/graphtest && dub build" (or "dub build --root=tests/graphtest").

Re: Template-heavy code and DUB

avatar
Joseph Rushton Wakeling
Posted Mon, 21 Oct 2013 12:05:25 GMT in reply to Sönke Ludwig
Reply

On Mon, 21 Oct 2013 11:42:55 GMT, Sönke Ludwig wrote:

Building then works simply using "cd tests/graphtest && dub build" (or "dub build --root=tests/graphtest").

Ahh, I see. I think then it might be helpful to have an opportunity to reference these as subpackages -- something akin to: 

"subPackages": [
    {
        "root": "tests/graphtest"     // automatically works out everything else from the local package.json
    }
]

... or is something like that already possible?

In any case, I think for now I'm happy with the subPackages solution I came to. Thank you ever so much for all your help here -- it's really been a joy having such fast and helpful feedback and bugfixes!

Re: Template-heavy code and DUB

avatar
Sönke Ludwig
Posted Mon, 21 Oct 2013 12:51:53 GMT in reply to Joseph Rushton Wakeling
Reply

On Mon, 21 Oct 2013 12:05:25 GMT, Joseph Rushton Wakeling wrote:

On Mon, 21 Oct 2013 11:42:55 GMT, Sönke Ludwig wrote:

Building then works simply using "cd tests/graphtest && dub build" (or "dub build --root=tests/graphtest").

Ahh, I see. I think then it might be helpful to have an opportunity to reference these as subpackages -- something akin to: 

"subPackages": [
    {
        "root": "tests/graphtest"     // automatically works out everything else from the local package.json
    }
]

... or is something like that already possible?

Something like 

"subPackages": [
	{
		"name": graphtest,
		"dependencies": {"graphtest": {"version": "~master", path="tests/graphtest"},
		"targetType": "none"}
	}
]

should work once that ticket is resolved. But frankly, I don't like the sub package feature that much, even if (or, rather, because) it is generally quite popular. While there are cases where sub packages are important to have (mostly so support existing source trees), they also facilitate certain not-so-clean approaches to organize a project (taking into account their public nature and the D module system). I think not only for this reason, there needs to be a basic "style guide" that gives an overview of when and why it makes sense to use each feature (build types, configurations, sub packages, distinct packages).

Other ideas can probably make distinct packages more attractive:

  • Display all those distinct sub folder packages in the registry, just like sub packages
  • Allow them to be referenced using the same syntax ("mainpackage:nameofpackageinsubfolder")
  • Support single file packages

If all these points are supported, I think that it will be safe to declare "subPackages" as a mildly discouraged compatibility feature without hampering any other use cases.

In any case, I think for now I'm happy with the subPackages solution I came to. Thank you ever so much for all your help here -- it's really been a joy having such fast and helpful feedback and bugfixes!

You're welcome! I'm always glad when things can be quickly fixed.

Re: Template-heavy code and DUB

avatar
Joseph Rushton Wakeling
Posted Mon, 21 Oct 2013 13:24:47 GMT in reply to Sönke Ludwig
Reply

On Mon, 21 Oct 2013 12:51:53 GMT, Sönke Ludwig wrote:

Other ideas can probably make distinct packages more attractive:

  • Display all those distinct sub folder packages in the registry, just like sub packages
  • Allow them to be referenced using the same syntax ("mainpackage:nameofpackageinsubfolder")
  • Support single file packages

If all these points are supported, I think that it will be safe to declare "subPackages" as a mildly discouraged compatibility feature without hampering any other use cases.

I guess from my point of view the crucial thing is that it's easy for me to be able to say, "Build everything that's part of this project," or, "Build this specified subset of the project," just as I can with my existing make setup. Dependencies don't always make sense for this -- certainly not in my case, because the test utilities are not something you want to build if for you dgraph is an upstream.

You're welcome! I'm always glad when things can be quickly fixed.

I'm pleased to announce that Dgraph is now in the DUB repository :-) Thanks once again!

Pages: 1 2