Saxon

Right. Sorry. More documentation is needed and I should test building
from the mirror repository more often. Let me see if I can document it
all this weekend sometime.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Norm Tovey-Walsh wrote in Gradle build message: "Incomplete configuration for test ...:

Right. Sorry. More documentation is needed and I should test building
from the mirror repository more often. Let me see if I can document it
all this weekend sometime.

Please let me know when you have any suggestion to move past the error. The repository I have used in the only that I would understand to host any current representation of the same code base.

Please let me know when you have any suggestion to move past the error. The repository I
have used in the only that I would understand to host any current representation of the
same code base.

It’s not a problem with the code base exactly. In order to make sure we
run all the tests, the build requires that the test locations be
configured. That’s (a) probably not necessary for casual builds and (b)
not documented well enough. It’s on my list. Apologies for the inconvenience.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

To add to that, you talk about "moving past the error", but I think it's very likely that the product has already been successfully built before you hit this error, and that the error occurs during the subsequent testing process.

To add to that, you talk about "moving past the error", but I think it's very likely that
the product has already been successfully built before you hit this error, and that the
error occurs during the subsequent testing process.

Perhaps. My off-the-top-of-my-head conclusion was more-or-less the
opposite. That during the configuration phase, Gradle is trying to make
sure it has all the testing stuff configured. It doesn’t and aborts.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Norm Tovey-Walsh wrote in RE: Gradle build message: "Incomplete configuration for t...:

It’s not a problem with the code base exactly. In order to make sure we
run all the tests, the build requires that the test locations be
configured. That’s (a) probably not necessary for casual builds and (b)
not documented well enough. It’s on my list. Apologies for the inconvenience.

The build instructions direct that I clone the test repositories, and set the appropriate environment variables to point to them. I have done both.

Norm Tovey-Walsh wrote in RE: Gradle build message: "Incomplete configuration for t...:

Perhaps. My off-the-top-of-my-head conclusion was more-or-less the
opposite. That during the configuration phase, Gradle is trying to make
sure it has all the testing stuff configured. It doesn’t and aborts.

Right. Ideally, I can finish the build, as the early target, and then if desired, and if the resource are available, then invoke the tests. Such options should be available whether or not the tests are included in the default target.

Norm Tovey-Walsh wrote in RE: Gradle build message: "Incomplete configuration for t...:

It’s not a problem with the code base exactly. In order to make sure we
run all the tests, the build requires that the test locations be
configured. That’s (a) probably not necessary for casual builds and (b)
not documented well enough. It’s on my list. Apologies for the inconvenience.

By the way, management of the dependent repos should be possible through some combination of Git submodules and Gradle tasks. In the old days, dependencies would need to be laid out manually, elsewhere on the developer's system, but the complexity of modern projects and the fast rate of change demands a higher level of automation for modern projects. I am wondering whether the current model is cumbersome enough that you might consider replacing through the capabilities of the tool chain.

You probably could add the repos as submodules to the main repo, and add a step to the build process, before the actual tests, for updating the child repos in the working dir. You could then invoke the tests in an environment pointing to the child locations.

FAILURE: Build failed with an exception.

• Where:
  Script '/saxonmirrorhe.he/test-suites.gradle' line: 364

This, I’ve fixed. But it doesn’t build for lots of reasons. Like Mike
said in another message, it’s a little unclear how much effort we should
put into this. (In principle, it should build, but in practice we build
HE/PE/EE from a common set of sources and the separation isn’t as clean
as one might like.)

The most obvious problem seems to be that a bunch of HE classes import
EE classes. The actual use of EE features is #ifdef’d out, but not the
imports. :-(

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

The actual use of EE features is #ifdef’d out, but not the imports

The preprocessor step should remove those imports.

Am I to understand that Saxonica maintains a project that it publicly presents as "open source", distributed as a source tree with included build scripts, but that is not supported as building without commercial dependencies that it also maintains?

Saxonica Developer Community notifications@plan.io writes:

The actual use of EE features is #ifdef’d out, but not the imports

The preprocessor step should remove those imports.

Yes, but we don’t push preprocessed code to the HE mirror repository, we
push our HE commits.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Am I to understand that Saxonica maintains a project that it publicly presents as "open
source", distributed as a source tree with included build scripts, but that is not
supported as building without commercial dependencies that it also
maintains?

It’s open source and you can get the HE sources (filtered so they will
build) from our HE source archive, same as it has been for years.

I made the HE mirror repository public a while ago, but it’s clearly
never been tested extensively.

If you just want the sources, getting the source archive is probably
easier.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

I don't understand.

If the public cannot build an open-source project, then I am speechless.

Norm Tovey-Walsh wrote in RE: Gradle build message: "Incomplete configuration for t...:

It’s open source and you can get the HE sources (filtered so they will
build) from our HE source archive, same as it has been for years.

I made the HE mirror repository public a while ago, but it’s clearly
never been tested extensively.

I don't understand.

We make the source code available in two forms:

(a) the true source, in the form that we maintain it and edit it, which has a complex build process, dependencies, and tools because the same source is also used to generate commercial products

(b) the preprocessed source, in a form that's much easier for people to handle if they just want to load the code into an IDE and compile it.

The first form is for compliance with the open source doctrine that what you release should be the code base that you develop and edit. The second form is for user convenience.

I'm interested to know what you are trying to achieve here: it's hard to help you without knowing that.

Michael Kay wrote in RE: Gradle build message: "Incomplete configuration for t...:

We make the source code available in two forms:

Which is represented in the repository from which is appearing the reported error message?

Michael Kay wrote in RE: Gradle build message: "Incomplete configuration for t...:

I'm interested to know what you are trying to achieve here: it's hard to help you without knowing that.

I understand, but at the same time, it would not be helpful for me to write at an arbitrary level of detail. Perhaps you might add texture to what you feel is helpful for me to share. The simple explanation, though it may be no more helpful that any already given, is that the objective is to understand how closely it is possible to achieve a process of pulling from a public repository into an open-source environment, and then building binaries that are essentially congruent with the distributed ones.

May I ask, why not organize the tree so that HE would have a simple build process, and also could be given as a constituent of EE?

For example, consider a build tree as follows:

• EE:
  • Build script (using advanced tool chain)
  • Source files
  • Generated build targets
  • HE:
    • Build script (using simple tool chain)
    • Source files
    • Generated build targets

As such, the script under HE would build the corresponding source, and would be able to do so standalone, generating the targets under it. The tree would be the sole distribution under an open license for the particular code base. Meanwhile, the build script under EE would invoke targets in the HE build script, and consume corresponding source files, as needed, as well as the further files particular to EE, to generate under it the complete set of targets for the EE.

I understand that more than two editions are maintained. The example illustrates a concept that may be generalized.

At any rate, the structure seems easier than what has been described, based on my cursory and almost certainly incomplete understanding.

(As a further enhancement, whichever build script is directly activated may invoke appropriate tests, placed at the same level.)