You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Gareth Reakes <ga...@parthenoncomputing.com> on 2005/04/05 11:21:13 UTC
New make output
Hi all,
I have applied the patch from Axel which makes the make output *much*
nicer. The changes seem standard
--- xml-xerces/c/src/xercesc/framework/psvi/Makefile.in 2004-09-08
18:53:11.000000000 +0200
+++ xml-xerces-modified/c/src/xercesc/framework/psvi/Makefile.in
2005-04-03 13:01:45.623939976 +0200
@@ -115,12 +115,14 @@
includes:: pubheaders $(PSVI_C_FILES)
pubheaders::
- -mkdir -p $(XML_INC_DIR)/$(MODULE)/$(SUBMODULE)
- $(CP) $(PSVI_CPP_PUBHEADERS) $(PSVI_C_FILES)
$(XML_INC_DIR)/$(MODULE)/$(SUBMODULE)
+ $Qmkdir -p $(XML_INC_DIR)/$(MODULE)/$(SUBMODULE)
+ @echo " (CP) $(XML_INC_DIR)/$(MODULE)/$(SUBMODULE)"
+ $Q$(CP) $(PSVI_CPP_PUBHEADERS) $(PSVI_C_FILES)
$(XML_INC_DIR)/$(MODULE)/$(SUBMODULE)
# this may generate unnecessary dependencies, but it makes life easier
depend:: includes
- $(MAKE_DEPEND) $(XML_INCL) *.cpp > $(DEPFILE)
+ @echo " (DEP)"
+ $Q$(MAKE_DEPEND) $(XML_INCL) *.cpp > $(DEPFILE)
If people could try this on other platforms that would be great.
Thanks Axel!
Gareth
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: New make output
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Am Dienstag, 5. April 2005 11:21 schrieb Gareth Reakes:
> Hi all,
>
> I have applied the patch from Axel which makes the make output
> *much* nicer. The changes seem standard
Hi,
I'm thinking about re-structuring and simplifying the Makefiles (e.g.
putting all configure-related and *very* redundand code into
Makefile.incl, thus not needing to process Makefile.in's in
subdirectories during configure any more).
Is there shared interest on this work to be done?
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: configuring xercesc (was: New make output)
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Axel Weiß wrote:
> I'd like to add another notion related to compililation: why gets all
> the platform-specific stuff for *all* platforms compiled (and linked
> into the library) when building for a particular platform?
Sorry for the noise - of course, this is nonsense...
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: configuring xercesc (was: New make output)
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Am Dienstag, 12. April 2005 05:45 schrieb James Berry:
> On Apr 11, 2005, at 7:31 AM, Axel Weiß wrote:
> > James, did you already develop a strategy for eliminating
> > runConfigure?
>
> Hi Axel,
>
> Sorry the for the delay in replying, I've been out of town for a day.
>
> Yes. I've got prototype autoconf infrastructure that eliminates both
> runConfigure and the need for XERCESROOT (as least as far as the
> build and test infrastructure is concerned). The options for
> runConfigure are sniffed into reasonable defaults by default; they
> can be overridden by --with and --without. So I think your comments
> are completely inline.
>
> This code is due to be checked into just as soon as we switch to svn
> and can start a broader reorganization of things. That seems to be
> held up by apache infrastructure at the moment, but hopefully we'll
> break it free soon.
>
> The other major task in supporting the broad variety of platforms is
> to refactor the Platform support, as well as write additional
> autoconfig test for various bits of functionality.
>
> See an earlier status email I sent on this subject (Feb 24), another
> email I sent regarding some autoconf thoughts (Feb 17), and our
> general release 3.x plan (releases_plan.html document in cvs -- I
> guess it never made it to the site).
Hi James,
indeed, your thoughts about re-structuring seem very promising. However,
I'd like to add another notion related to compililation: why gets all
the platform-specific stuff for *all* platforms compiled (and linked
into the library) when building for a particular platform? I believe
that it is possible and much more efficient to only compile the
platform-related sources belonging to the target, and skip compiling the
others. This could be managed by configure/Makefile.
Just an idea...
> Your thoughts, comments and help are all welcome. Hopefully we'll get
> the svn stuff out of the way relatively soon so we can more readily
> begin our 3.x migration.
James, would you like to send me what you have done so far?
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: configuring xercesc (was: New make output)
Posted by James Berry <jb...@apache.org>.
On Apr 11, 2005, at 7:31 AM, Axel Weiß wrote:
> James, did you already develop a strategy for eliminating
> runConfigure?
Hi Axel,
Sorry the for the delay in replying, I've been out of town for a day.
Yes. I've got prototype autoconf infrastructure that eliminates both
runConfigure and the need for XERCESROOT (as least as far as the
build and test infrastructure is concerned). The options for
runConfigure are sniffed into reasonable defaults by default; they
can be overridden by --with and --without. So I think your comments
are completely inline.
This code is due to be checked into just as soon as we switch to svn
and can start a broader reorganization of things. That seems to be
held up by apache infrastructure at the moment, but hopefully we'll
break it free soon.
The other major task in supporting the broad variety of platforms is
to refactor the Platform support, as well as write additional
autoconfig test for various bits of functionality.
See an earlier status email I sent on this subject (Feb 24), another
email I sent regarding some autoconf thoughts (Feb 17), and our
general release 3.x plan (releases_plan.html document in cvs -- I
guess it never made it to the site).
Your thoughts, comments and help are all welcome. Hopefully we'll get
the svn stuff out of the way relatively soon so we can more readily
begin our 3.x migration.
James.
> A brief analysis shows to me two main tasks of runConfigure:
> 1. offer to the user a convenient way to specify platform, compiler
> and
> xerces-modules like transcoder, net accessor and message loader
> 2. set some environment variables according to the user's choice
> (which
> are then used by configure only).
>
> So one possible way to eliminate runConfigure could be:
> 1. map the arguments of runConfigure to arguments of configure. There
> are some standard-ways to pass configure-arguments (e.g. platform
> would
> be --target, misc-options would be --with-* or --without-*), and
> configure tends to determine the compiler by it's own, if the CC
> environment variable is not set.
> 2. Integrate the functionality of runConfigure into configure.in. All
> the environment variables exported by runConfigure can then be
> dropped.
> 3. configure and configure.in should be moved to $XERCESCROOT. This
> would require to have also a Makefile.in in $XERCESCROOT.
> 4. The environment variable XERCESCROOT may be eliminated as well.
>
> Any comments on this?
>
> Axel
>
> --
> Humboldt-Universität zu Berlin
> Institut für Informatik
> Signalverarbeitung und Mustererkennung
> Dipl.-Inf. Axel Weiß
> Rudower Chaussee 25
> 12489 Berlin-Adlershof
> +49-30-2093-3050
> ** www.freesp.de **
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org