avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] Re: circ dep fix


From: Theodore Roth
Subject: [avr-libc-dev] Re: circ dep fix
Date: Fri, 2 Aug 2002 10:37:32 -0600 (MDT)

On Fri, 2 Aug 2002, Joerg Wunsch wrote:

:) Well, i'd rather prefer to separate them, so that bug fixes and
:) feature extensions remain distinct in CVS.  Also, i'm not even sure
:) i like my current way of doing things :), it's merely a proposal.

I think a better approach for the pdf version would be to add
--with-pdlatex to configure.in.

:)
:) It should not be much of a problem when you commit something to that
:) file, that's what the `C' in CVS stands for.  Coming from FreeBSD
:) which has been using CVS for almost ten years in a project joining
:) several hundred committers, i'm also used to get an unresolvable CVS
:) conflict occasionally that needs to be resolved manually. ;-)

I agree. I was just time constrained and lazy last night. Sorry.

:)
:) So feel free to commit the circular dependency fix first, the PDF
:) changes probably need to wait a bit to mature.

I'll make the fix today.

:) Hmm, i need to see the resulting Makefile.am before judging that.  But
:) what occurs to me when seeing this: it's perhaps a bad idea to have
:) targets that are named similar to a directory.  While the current
:) Makefile structure is heavily gmake-bound anyway (by using ${MAKE} -C
:) ${dir}), this could in theory be fixed (cd ${dir} && ${MAKE}.  Other
:) make utilities might stumble across it then since they evaluate the
:) timestamp for that directory which is rather intended to be a `phony'
:) target.

I agree with dir targets being sub-optimal. It was a hack on my part which
I will try to clean up.

:)
:) So in short, i prefer the dox-foo style (also for the other targets
:) like latex).

There's another problem I had last night. Edit some Makefile.am, rerun
reconf, then run `make clean` in the build dir. Goes into a nice infinite
loop. Grrrr! I think this is an artifact of the multilib setup, but since
I didn't write that, it will take a bit more investigating to figure out
the problem.

Can we move this discussion to the avr-libc-dev list so there's a record
of it and others can see what we're doing? I've CC'd the list, so just
reply to the list instead of me directly.

Ted Roth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]