Can cppalloc.c be removed?

Can cppalloc.c be removed?

[Kaveh R. Ghazi]

Now that libiberty.a is linked with everywhere (except for modules
including hconfig.h,) can cppalloc.c be removed or is libcpp.a
expected to be usable as a standaline library and therefore must
provide its own xmalloc, etc?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Can cppalloc.c be removed?

[Per Bothner]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Now that libiberty.a is linked with everywhere (except for modules
> including hconfig.h,) can cppalloc.c be removed or is libcpp.a
> expected to be usable as a standaline library and therefore must
> provide its own xmalloc, etc?

One of the goals of cpplib is that it can be used as a stand-alone
library with a public API.  One obvious application is using cpplib to
mscro-expand C/C++ expressions when typed at the Gdb command line.

One reason for a separate cppalloc.c was to provide some flexibility;
specifically, I did not want xmalloc etc to be *required*, just because
cpplib might be linked with aplications that have their own xmalloc.

I don't know if this specifically answers your question.  Note that
Gdb does use libiberty, and does use (a version of) xmalloc.  So I
suspect you can remove cppalloc.c, as long as we specify in the cpplib
public interface that the cpplib client must provide xmalloc etc.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

Re: Can cppalloc.c be removed?

[Per Bothner]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Now that libiberty.a is linked with everywhere (except for modules
> including hconfig.h,) can cppalloc.c be removed or is libcpp.a
> expected to be usable as a standaline library and therefore must
> provide its own xmalloc, etc?

One of the goals of cpplib is that it can be used as a stand-alone
library with a public API.  One obvious application is using cpplib to
mscro-expand C/C++ expressions when typed at the Gdb command line.

One reason for a separate cppalloc.c was to provide some flexibility;
specifically, I did not want xmalloc etc to be *required*, just because
cpplib might be linked with aplications that have their own xmalloc.

I don't know if this specifically answers your question.  Note that
Gdb does use libiberty, and does use (a version of) xmalloc.  So I
suspect you can remove cppalloc.c, as long as we specify in the cpplib
public interface that the cpplib client must provide xmalloc etc.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

Can cppalloc.c be removed?

[Kaveh R. Ghazi]

Now that libiberty.a is linked with everywhere (except for modules
including hconfig.h,) can cppalloc.c be removed or is libcpp.a
expected to be usable as a standaline library and therefore must
provide its own xmalloc, etc?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Can cppalloc.c be removed?

[Per Bothner]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Thanks for the information.  After some poking around, I don't think
> we can remove cppalloc.c just yet.  We link libcpp.a with fix-header
> and gen-protos.  Neither of them is linked with libiberty.a because
> they are "build" ("host"?) programs.

fix-header and gen-protos (like fix-includes) should only be run
when build==host==target, so I don't think that is a problem.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

Re: Can cppalloc.c be removed?

[Kaveh R. Ghazi]

 > From: Per Bothner <per@bothner.com>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > Now that libiberty.a is linked with everywhere (except for modules
 > > including hconfig.h,) can cppalloc.c be removed or is libcpp.a
 > > expected to be usable as a standaline library and therefore must
 > > provide its own xmalloc, etc?
 > 
 > One of the goals of cpplib is that it can be used as a stand-alone
 > library with a public API.  One obvious application is using cpplib to
 > mscro-expand C/C++ expressions when typed at the Gdb command line.
 > 
 > One reason for a separate cppalloc.c was to provide some flexibility;
 > specifically, I did not want xmalloc etc to be *required*, just because
 > cpplib might be linked with aplications that have their own xmalloc.
 > 
 > I don't know if this specifically answers your question.  Note that
 > Gdb does use libiberty, and does use (a version of) xmalloc.  So I
 > suspect you can remove cppalloc.c, as long as we specify in the cpplib
 > public interface that the cpplib client must provide xmalloc etc.
 > -- 
 > 	--Per Bothner

Thanks for the information.  After some poking around, I don't think
we can remove cppalloc.c just yet.  We link libcpp.a with fix-header
and gen-protos.  Neither of them is linked with libiberty.a because
they are "build" ("host"?) programs.

I think we'll eventually compile both "host" and "build" copies of
libiberty.a, but until then we need cppalloc.c.

Now something doesn't look right, libcpp.a is linked with both "host"
and "build" programs but I see no mechanism to compile two copies of
it.  It something wrong here, or am I not seeing things right?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

Re: Can cppalloc.c be removed?

[Per Bothner]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> Thanks for the information.  After some poking around, I don't think
> we can remove cppalloc.c just yet.  We link libcpp.a with fix-header
> and gen-protos.  Neither of them is linked with libiberty.a because
> they are "build" ("host"?) programs.

fix-header and gen-protos (like fix-includes) should only be run
when build==host==target, so I don't think that is a problem.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/

Re: Can cppalloc.c be removed?

[Kaveh R. Ghazi]

 > From: Per Bothner <per@bothner.com>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > Now that libiberty.a is linked with everywhere (except for modules
 > > including hconfig.h,) can cppalloc.c be removed or is libcpp.a
 > > expected to be usable as a standaline library and therefore must
 > > provide its own xmalloc, etc?
 > 
 > One of the goals of cpplib is that it can be used as a stand-alone
 > library with a public API.  One obvious application is using cpplib to
 > mscro-expand C/C++ expressions when typed at the Gdb command line.
 > 
 > One reason for a separate cppalloc.c was to provide some flexibility;
 > specifically, I did not want xmalloc etc to be *required*, just because
 > cpplib might be linked with aplications that have their own xmalloc.
 > 
 > I don't know if this specifically answers your question.  Note that
 > Gdb does use libiberty, and does use (a version of) xmalloc.  So I
 > suspect you can remove cppalloc.c, as long as we specify in the cpplib
 > public interface that the cpplib client must provide xmalloc etc.
 > -- 
 > 	--Per Bothner

Thanks for the information.  After some poking around, I don't think
we can remove cppalloc.c just yet.  We link libcpp.a with fix-header
and gen-protos.  Neither of them is linked with libiberty.a because
they are "build" ("host"?) programs.

I think we'll eventually compile both "host" and "build" copies of
libiberty.a, but until then we need cppalloc.c.

Now something doesn't look right, libcpp.a is linked with both "host"
and "build" programs but I see no mechanism to compile two copies of
it.  It something wrong here, or am I not seeing things right?

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions