Modular build system

[GoogleCodeExporter]

This is in response to:

http://code.google.com/p/cudpp/issues/detail?id=18
http://code.google.com/p/cudpp/issues/detail?id=19
http://code.google.com/p/cudpp/issues/detail?id=107
http://code.google.com/p/cudpp/issues/detail?id=112

Make cudpp's build system modular, so that algorithms, data types, operators 
and compute targets can be enabled/disabled individually. As suggested by Mark 
Harris (http://code.google.com/p/cudpp/issues/detail?id=112#c2), CMAKE settings 
should be added for this.

Open question: Should data types and operators be enabled/disabled globally, or 
for every algo/type/op combo, or something in between? The second option would 
allow the most fine-grained selection, but result in *a lot* of build settings.

Original issue reported on code.google.com by m0b...@gmail.com on 1 Mar 2012 at 10:33

[GoogleCodeExporter]

I'm inclined to do it by datatype. The settings won't look like this, but in 
effect: --enable-short, --enable-uchar, that sort of thing. The datatypes used 
by any particular developer in a program are usually a subset of all datatypes, 
and once a datatype is enabled, we'd like to enable all possible operations on 
it (scan, reduce, etc.). Again just a strawman, happy to take comments from all 
stakeholders here.

Original comment by jow...@gmail.com on 1 Mar 2012 at 4:58

[GoogleCodeExporter]

I agree that it makes sense to do data types globally. But for operators, it's 
not so clear: For example, min and max are common for reduce, but I can't see 
many uses for a min/max scan. But maybe it is already enough to disable 
uncommon data types and leave all operators enabled.

It should also be easy and effective to specify the compute targets: If I only 
care about Fermi hardware, disabling the 1.0 and 1.3 targets should already 
reduce build time and binary size to a third.

I'd be willing to work on this when I get some time (probably in April or 
May...)

Original comment by m0b...@gmail.com on 5 Mar 2012 at 1:50

[GoogleCodeExporter]

Your help would be greatly appreciated. There's two pieces here: one is putting 
a whole bunch of #defines into the source code (no big deal). Two is wrestling 
cmake into doing the right thing. I know how to do 1. I don't know how to do 2 
(Mark did all the cmake magic). Anyway, any help would be awesome.

Original comment by jow...@gmail.com on 5 Mar 2012 at 7:24

[GoogleCodeExporter]

2 should also be no big deal if you know how to use cmake. Which I don't, but I 
should learn that anyway :)
So I'll have a look at that in a few weeks...

Original comment by m0b...@gmail.com on 6 Mar 2012 at 10:22

[GoogleCodeExporter]

Attached is a patch to enable/disable support for individual data types.
It adds a CMake option to enable/disable each type (CUDPP_ENABLE_UCHAR etc); 
these are passed as #defines to the code, where all the data type cases are 
#ifdef'd.

By default, only int, uint and float are enabled (though this is easy to 
change).

This also includes my earlier patch for short/ushort support in scan and reduce 
(now disabled by default).

Possible future extension: Similarly allow disabling some operations, e.g. not 
everybody needs segmented scan.

Original comment by m0b...@gmail.com on 24 Apr 2012 at 12:20

Attachments:

• disable_data_types.patch

[GoogleCodeExporter]

This is a bump: Is there still any interest in this? Any feedback; should 
something be done differently?

Original comment by m0b...@gmail.com on 27 Jun 2012 at 10:05

[GoogleCodeExporter]

Interest: definitely.  Time? Very little.

Original comment by harr...@gmail.com on 10 Sep 2012 at 10:08