Closed Jafaral closed 3 years ago
@StephenWampler
here is the new option:
./configure --htmldir=/var/www/html/unicon
The result is a variable written to two files
Makefile
Makefile.uni
In your case you want to include Makefile.uni probably to have the new variable available to you. I assume that would be the root directory and you would build a doc tree underneath it if you need to.
jafar@jtr:~/unicon$ tail -n 5 Makedefs.uni
libdir=${exec_prefix}/lib
docdir=${datarootdir}/doc/${PACKAGE_TARNAME}
mandir=${datarootdir}/man
htmldir=/var/www/html/unicon
datarootdir=${prefix}/share
The two options are available allowing the user to turn on the ones they want if they know what they are doing. We should document all options in the "developer guide" when that is a thing.
I don't know what you mean bu setting the environment variable from the build perspective. The variable should be set by the user in whatever context/shell they are running with. Ore are you just referring to to the test on Github CI ?
The two options are available allowing the user to turn on the ones they want if they know what they are doing. We should document all options in the "developer guide" when that is a thing.
I don't know what you mean bu setting the environment variable from the build perspective. The variable should be set by the user in whatever context/shell they are running with. Ore are you just referring to to the test on Github CI ?
The latter: the test on GitHub CI should make sure that the heap verifier is active; otherwise we might think we are enabling it, but in reality nothing is happening.
@Don-Ward I pushed a change to set VRFY to -2 when doing make Test. I wasn't sure if I want to add it to the build itself as well to trigger the code when building IPL and Unicon libraries. I left that out.
@Don-Ward I pushed a change to set VRFY to -2 when doing make Test. I wasn't sure if I want to add it to the build itself as well to trigger the code when building IPL and Unicon libraries. I left that out.
@Jafar It's up to you; but my preference would be to enable it when building the system itself (on just the one build where the heap verifier is enabled). It would be a much more thorough test and, even if the verifier caused a controlled crash, it wouldn't affect any other builds.
I defined VRFY globally on Linux for build and test. I'm assuming if VerifyHeap is not defined then VRFY doesn't do anything, correct ? Maybe it worth enabling debug and verify heap on multiple of those tests anyway, but I'll leave that for another experiment.
The result is a variable written to two files | |||
---|---|---|---|
Makefile | |||
Makefile.uni | |||
In your case you want to include Makefile.uni probably to have the new variable available to you. I assume that would be the | root directory and you would build a doc tree underneath it if you need to. |
It would be nice if the last few lines of Makedefs.uni could be sourced from a script and not just from a Makefile. either by moving the make rules someplace else or putting those last lines in a file that could be include by both Makedefs.uni and scripts.
Otherwise, this is fine.
It would be nice if the last few lines of Makedefs.uni could be sourced from a script and not just from a Makefile. either by moving the make rules someplace else or putting those last lines in a file that could be include by both Makedefs.uni and scripts.
@StephenWampler What kind of script? where/how are you going to invoke it ?
| What kind of script? where/how are you going to invoke it ?
In my case, bash and zsh scripts that call Unicon programs with preset parameters. For example, I use UniDoc to maintain web pages on my private Unicon programs but want to link those pages back into those created for the 'standard' unicon/uni and unicon/ipl support.
Come to think of it, it would also be nice if these defines could be embedded in the environment make available to Unicon programs via the getenv() call.
Ok, so the scripts you are referring to are not part of Unicon itself. I think this is out of scope of what the configure script ought to be doing but that doesn't mean we can't do it. Such variables should be baked into the binaries themselves probably where you can ask unicon what does it think the html pages are located. I will think about that a little more. I'm going to go ahead and merge this PR the if you have no objections @StephenWampler .
No objection!
--enable-debugheap --enable-verifyheap --htmldir
Also better detection of whether the C compiler really supports Wno-parentheses-equality or not
Signed-off-by: Jafar Al-Gharaibeh to.jafar@gmail.com