Bug 1182

Summary:	./waf --doxygen-no-build does not work
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	build system	Assignee:	Gustavo J. A. M. Carneiro <gjcarneiro>
Status:	RESOLVED INVALID
Severity:	normal	CC:	ns-bugs
Priority:	P5
Version:	pre-release
Hardware:	All
OS:	All

Description Tom Henderson 2011-06-07 10:34:25 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..."

Comment 1 Tom Henderson 2011-06-07 11:06:30 UTC

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.

Comment 2 Gustavo J. A. M. Carneiro 2011-06-26 08:46:14 UTC

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.

Comment 3 Tommaso Pecorella 2011-06-26 10:24:47 UTC

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

Comment 4 Gustavo J. A. M. Carneiro 2011-06-27 10:04:08 UTC

(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.

Comment 5 Tom Henderson 2011-06-27 23:23:28 UTC

(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.

Comment 6 Tommaso Pecorella 2011-06-28 15:21:34 UTC

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).