And Chris Wailes writes:
> While I have had issues with software that has used Autoconf in
> the past it has been a while since that has been the case. The
> advent of modern package management systems and programs like
> pkg-config have made their use a lot less problematic.
It's great if you buy into the whole system and it doesn't
change... again. Then there's the issue of developers needing to
match just the right versions of the auto-tools.
> Most projects that use these systems these days can be
> installed by running `cmake; make; make install`.
Erm, you mean 'mkdir build; cd build; cmake ..; make; make
install prefix=${HOME}/foo; rm -rf ${HOME}/foo; cmake
SOMECFGVARINEVERREMEMBER=${HOME}/foo ..; make; make install;
rm -rf ${HOME}/foo; make clean; make; make install', right?
> CMake, at least, has built in and dedicated support for
> cross-compiling:
So does autoconf. Both tools have painful warts, but that's
because the *problem* has painful warts, and not just for
cross compiling. (Really, the embedded world is the place to
look for good cross compiling methods... Some cool methods use
emulators / VMs to run test programs.)
CMake generates non-Makefile build scripts, and that can be
hugely helpful for the GUI-addled.
> One reason I would like a configuration system is because I
> have written a more generalized tracing infrastructure for my
> own needs but I wouldn't want to release it to the wider
> community without others being able to turn it off very easily
> and still retain all of the other features enabled by setting
> CHPL_DEVELOPER.
So a CHPL_TRACING variable? Sounds like that might be useful for
some deployment situations, depending on the overhead.
Chapel may not be at a point yet where fiddling with cmake or
autoconf to support the multitude of compilers & runtimes &
targets is better than fiddling with the makefile to support the
multitude of compilers & runtimes & targets (um, sunos support?).
Other projects have tackled ./configure addiction with a custom
./configure that generates the make.inc... That might be the
first step, just to figure out what enable/disable and library
location options are needed.
The zero'th step would be converting to git, of course.
--
Jason
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
