Bugzilla – Bug 1182
./waf --doxygen-no-build does not work
Last modified: 2011-08-09 16:11:09 UTC
hg clone http://code.nsnam.org/ns-3-dev && cd ns-3-dev ./waf --doxygen-no-build yields: "print-introspected-doxygen has not been built yet. You need to build ns-3 at least once before generating doxygen docs..."
if we decide to keep this option (one possible solution is to remove this option, and I wouldn't object strongly to removing it), we need to add support to buildbot scripts to test this.
I think the option does what is intended. When I was writing doxygen once I felt the need to have this option, else to call the doxygen compiler would keep building the whole ns-3 tree every time. Sure, you need to build ns-3 at least once, but after that one time you can keep changing the documentation in the headers and test doxygen right after without needing to rebuild. For me, the option is not broken and is still useful. I didn't respond sooner because I thought the option stopped working and required bug fixing, but it is not the case.
What about a conditional build ? I mean, changing the behavious so: 1) if ns-3 has been built, keep existing behaviour 2) if ns-3 hasn't been built ever, build it once This could fix the issue and at the same time keep the usefulness of the option. Tommaso
(In reply to comment #3) > What about a conditional build ? > > I mean, changing the behavious so: > 1) if ns-3 has been built, keep existing behaviour > 2) if ns-3 hasn't been built ever, build it once > > This could fix the issue and at the same time keep the usefulness of the > option. Yes, but at the risk of making the developer angry by disobeying his "no-build" request. At least this way we explain to him why we can't fulfill the request. I don't object doing this, but I personally don't feel there's much to gain with it.
(In reply to comment #4) > (In reply to comment #3) > > What about a conditional build ? > > > > I mean, changing the behavious so: > > 1) if ns-3 has been built, keep existing behaviour > > 2) if ns-3 hasn't been built ever, build it once > > > > This could fix the issue and at the same time keep the usefulness of the > > option. > > Yes, but at the risk of making the developer angry by disobeying his "no-build" > request. At least this way we explain to him why we can't fulfill the request. > > I don't object doing this, but I personally don't feel there's much to gain > with it. I would be fine with just marking INVALID; I thought it was originally working by just generating the introspection program and had been broken during the modular build cutover. I don't think it matters much to optimize this further.
I do agree, the error message should be clear enough even for the average dumb user (I know a couple that are dumb more than the average and would be blocked by it, they're usual reply is "the manual doesn't say anything about that". Sigh).