Custom Query (15 matches)

these build_*h files also cannot be built if feisty is not writable. they are needed for the c++ configurations. how can that live in a generated location though? the c++ code actually needs to see it.

this bug may be DOA. we can't really move these files up, nor the manifest file. but if you were handed the code, they would be part of what told you how it had been built. so, probably this one also goes right to solved. or won't fix.

original note:

refactor the build_*h files to not live in top of feisty.

=> how does the build refer to them then? oops. they kind of need to live in a known source code place.

refactor the manifest.txt to not live in top of feisty.

any similar concern to the build*h?

the output file for the bad links is really tiny, and has none of the category structure of the original file.

this is not super horrible, since now the link parser understands missing categories a bit better and can cope. the marks checker can actually operate on the bad links output of a former run and just bitches about missing categories but doesn't fail.

hmmm. leaning towards closing this one right away.

these are quite old dlls. replace them with newest.

• have done research to find code at least. check the big data chubby transfers area.

we don't want to store someone else's codebase, it's just the dlls we need. a debate raged over whether to store them at all, but since they aren't part of windows and since there's no package management for windows that can easily get the latest and best versions, we still will just store built versions so feisty meow can itself just build properly on windows. this decision can be revisited later.

so the best thing would be to personally rebuild these libraries with the latest.

then record the version level of each dependency for future reference, plus the location of the download.