Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More than one call to stapi::init can confuse existing speedtables #53

Open
mutability opened this issue Mar 17, 2016 · 5 comments
Open
Assignees

Comments

@mutability
Copy link

(I hesitate to call this a bug, but it causes very non-obvious failures)

If you call stapi::init twice with different -dir values, then any ctables managed by stapi that were created between the two calls get confused because they can no longer find their working files (as [workname $ctable foo] starts returning a different value)

It might make sense to store the build dir used during init_ctable per ctable, so that later changes to build_root do not make things fail.

@resuna
Copy link
Member

resuna commented Apr 3, 2016

What's the use case for calling stapi::init with different directories? I don't think that should be necessary.

@mutability
Copy link
Author

Packages that want to use stapi that are not aware of each other.

@resuna
Copy link
Member

resuna commented Apr 6, 2016

There is an attempted fix for this in the stapi-fixes branch. It keeps track of the directory associated with each base filename, and keeps using it.

I'm also pondering whether ignoring subsequent calls to init would be better.

Can you see if this fix works for your use case?

@resuna
Copy link
Member

resuna commented May 27, 2016

I have rebased the stapi-fixes branch up to master. Can you please verify that it fixes this problems so I can merge it back?

@resuna
Copy link
Member

resuna commented Jul 11, 2016

Should be fixed with merge of stapi-fixes. @mutability - could you check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants