>
> I may be missing something, but wouldn't the presence of conditional code
> that does or does not use C++11 features depending on whether or not
> they're available undo any readability features that using the features
> enabled?
You can conditionally define move constructors and assignment operators in
a class and then leave it up to the compiler to figure out when it is
appropriate to use them. This doesn't require any changes to code that
uses the class and provides most of the benefits. It would even be
possible to create a version of std::move that is effectively a noop in the
absence of RValue references.
As I said in the original thread, I'm mostly ignorant of Cmake (which I
> sense you're advocating more strongly for than autoconf).
While my preference IS CMake, it is only a slight preference (I do like
using Ninja). Mainly I'm just interested in having a configuration system.
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.
>
These days the RPM and DPkg systems are pretty stable. And eventually you
need to declare some dependencies for your software. The nice thing about
using a configuration system though is it allows you a lot more flexibility
with your other dependencies. Require a certain version of CMake or
autotools and then allow them to figure out what versions of Chapel's other
dependencies are available and if they work. This might also allow Chapel
to stop shipping so much 3rd party software along with it.
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?
>
Sure, if the project has poorly written CMake files. It's certainly
possible to write good ones. And the build directory isn't necessary, it's
just standard practice and a nice feature to have. A lot of that also
seems to be stuff you are passing to make or would have to pass to make the
way things stand right now. If I want to use Clang to compile Chapel I
have to remember to keep passing in the CC and CXX arguments. With
CMake/Autoconf I'd at least only have to do that when I was configuring the
system, not all of the time.
So a CHPL_TRACING variable? Sounds like that might be useful for
> some deployment situations, depending on the overhead.
It's actually a set of variables. One turns enables the tracing subsystem
and the rest enable/disable tracing of specific features. I need to get it
hooked into the --explain-call machinery because right now compiling a file
will generate a VERY large trace (we're talking MiB here). This is one of
the reasons I have it so you can select what processes you want to trace.
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.
I think the first step would be to re-create the current Makefile
functionality in CMake/Autoconf, and then add additional flexibility to the
system later. Adding support for using the CC and CXX environmental
variables would be an example, and a fairly easy one to accomplish at that.
The zero'th step would be converting to git, of course.
I didn't want to bring up too many issues at once, but I would be in favor
of a switch to Git. I'm pretty sure SourceForge supports it as an option,
so it wouldn't even require a switch over to GitHub (though I would also be
in favor of that).
- Chris
On Wed, Dec 11, 2013 at 4:56 PM, Jason Riedy <[email protected]>wrote:
> 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
>
------------------------------------------------------------------------------
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
