small improvements for -S switch about l3build HOT 13 OPEN

Additional note:

I ran my check that produced the output above from latex2e/required, so it found firstaid-pgfmorepages in need for updates and the first line doing the saving worked. However the second did but failed with

Bundle checks should not list test names

I understand why, but maybe then it should explicitly say that one needs to cd in the right directory or not give that advice with detailed file names to test if it is in a bundle directory.

from l3build.

You get 2 lines for execution but they are separated by a comment, e.g.,

To regenerate the test files, run

  l3build save firstaid-pgfmorepages

To detect engine specific differences, run after that

  l3build check --show-saves firstaid-pgfmorepages

Well isn't that by-design, so the information on what the steps actually are for is there? (One related things is we shouldn't have the second part if there is only one engine set up: I've spotted that a few times and now you remind me, I should fix it ...)

from l3build.

yes it is and I question that design :-). My point is that after I have run the first block there is so much clutter in the terminal that I can't get to the second block without a lot of trouble. Given that I would run both anyway it would be nice to be able to do so without copying both blocks somewhere.

For example, the output could include a comment char in front of the explanations (based on the OS you are using) then you can run both by simple copy and past if you want to

from l3build.

The second is this: I did l3build check -S -epdftex and on the LaTeX suite that runs quite long :-) if you test all engines. In the end it didn't produce any output because one of the test directories TU... doesn't run with pdftex and so when it was trying to make the above display l3build ran into a low-level error rather than displaying the results of the other test dirs it did process. That is a bit more of an issue in my opinion.

I think this one deserves a separate issue, as it's not about -S per se. We have a few places where variations in engine selection don't play nicely with multiple configurations, and this is one. Perhaps rather than -e<engine> we could do with a switch to use only the standard/default check engine (so --default/-d, or --standard-engine or ...)?

from l3build.

yes it is and I question that design :-). My point is that after I have run the first block there is so much clutter in the terminal that I can't get to the second block without a lot of trouble. Given that I would run both anyway it would be nice to be able to do so without copying both blocks somewhere.

This I guess depends on your workflow: IO only ever use the 'engine check' part selectively. But I can live with a change: coming up shortly.

from l3build.

I must admit I rarely use save (especially in repos that have large dependency setup). If check fails and I want to pass the diff, I don't regenerate, I simply copy the log file listed in the failing diff to the appropiate .tlg. If you just ran l3build check the required tlg is sitting in the build directory, you don't need to re-generate. (I usually do that by hand although a version of l3build save that did just that would save a bit of copying file paths.

from l3build.

It's a way of working, I agree. But I do differently. I do check with save (when I expect changes) and let my git GUI tell me what difference there are if any and then I decide if I want to check them in or figure out why something has changed that shouldn't have.

from l3build.

I think this one deserves a separate issue, as it's not about -S per se. We have a few places where variations in engine selection don't play nicely with multiple configurations, and this is one. Perhaps rather than -e<engine> we could do with a switch to use only the standard/default check engine (so --default/-d, or --standard-engine or ...)?

sure fine with me. I just noticed it in passing, but it seems to me an -S issue, because it fails due to one intermediate step failing and then doesn't list anything not even the ones that it had discovered earlier.

from l3build.

I realise that we have almost-duplicated code for the info: once at the end of a single run, and once in the top-level code for where we have more than one config. That means things get a little messy, and it's not ideal. Is having both outputs sensible? If so, I guess I should make a single function for the rerun info.

from l3build.

You mean if you have 3 config files in a directory and you run -S and then you get one summary after each config? and a final one summarising all of them? The middle ones are not really helpful I guess since they are basically flying by and in the terminal it would be hard to find them again (unless you interrupt in the middle that is).

from l3build.

@FrankMittelbach Indeed: I wonder if I should move the checks just to the top level

from l3build.

@FrankMittelbach Indeed: I wonder if I should move the checks just to the top level

@josephwright probably

from l3build.

I took a bit more of a look at this yesterday: I think now I see why @zauguin set things up as they are.I'll make sure I edit in the two places that are important - perhaps today, perhaps over the weekend.

from l3build.