[CoinBinary] CppAD and the coinbinary packing effort

[Brad Bell]

I recently converted CppAD to use cmake for its build process; see
     http://www.coin-or.org/CppAD/Doc/install.xml

I have tested this with Microsoft Visual Studio and it works well with 
the corresponding nmake files (or project files). It would be nice to 
have someone test and report how this works on the Mac and if there are 
problems.

As I understand, cmake can also generate rpms. Perhaps this is relevant 
to the packing effort being discussed on this mailing list ?

There is a cppad fedora package (I maintain) that one can get with
     yum install cppad-devel cppad-doc
The build process for this package mainly does testing  before creating 
its noarch rpm. I have not included the cppad_ipopt library in this 
build; see
     http://www.coin-or.org/CppAD/Doc/cppad_ipopt_nlp.xml
because it would require ipopt and it would be arch specific.

The CppAD tarballs have the documentation included so the user does not 
have to build it. The system used to build the documentation is called 
omhelp; see
     http://www.seanet.com/~bradbell/omhelp/install.xml

Starting in 2010, there has been a new stable version of CppAD at the 
beginning of each year; see
     https://projects.coin-or.org/CppAD/browser#stable
I use the the corresponding gpl tarballs in
     http://www.coin-or.org/download/source/CppAD/
for the Fedora package.




On 11/24/2012 03:02 PM, Matthew Saltzman wrote:
> On Sat, 2012-11-24 at 17:23 -0500, Ted Ralphs wrote:
>>
>> On Sat, Nov 24, 2012 at 1:58 PM, Matthew Saltzman <mjs at clemson.edu>
>> wrote:
>>          >
>>          > > However, some users might still
>>          > > like to be able to download the monolithic tarball. I am
>>          thinking that the
>>          > > best thing to do is to post two tarballs for each
>>          project---one with
>>          > > dependences and one with just the subdirectory.
>>          >
>>          > I think this is a possible solution.
>>          > Do you see a way to put up these extra tarballs only for
>>          versions that
>>          > are included in Fedora? Do they pack the packages or do you
>>          does this?
>>          > Maybe these no-dependencies sources could just go to a
>>          separate
>>          > directory on the coin-or server and be uploaded in the
>>          process of
>>          > creating packages?
>>          
>>          
>>          Someone (probably from our organization) will need to be
>>          responsible for
>>          maintaining the RPMs, but it would be preferable for
>>          accessibility if
>>          they were part of the Fedora distribution.  There are a bunch
>>          of
>>          automated build tools used there that we would need to work
>>          with (but
>>          that we might learn from).  Alternatively, we could host the
>>          RPMs
>>          ourselves.  In that case, we would still need appropriate
>>          tarballs
>>          packaged, but we wouldn't need to work with the Fedora
>>          systems.  We
>>          should still do whatever we can to conform to their packaging
>>          standards.
>>
>> This is coming up because a guy named Paulo César Pereira de Andrade
>> has taken up the cause of packaging all the COIN-OR projects and is
>> going to submit them for approval. He seems very knowledgeable and
>> experienced with the process and if you look at his Fedora page, it
>> looks like he does the packaging for Sage and numpy. It would be good
>> for us to be associated with them somehow.
>>
>> http://fedorapeople.org/~pcpa/
>>
>> Our conversation about all of this is mostly archived on the
>> CoinBinary mailing list, which it seems no one is subscribed to except
>> me :). I've been assuming he would be the one to maintain the RPMs
>> make new ones when there are releases, etc. I don't think we have to
>> do much except make things ready from our side. Hence, the
>> project-only tarballs.
>>   
>>          Either way, it would be fine to keep those tarballs in a
>>          separate space
>>          from the standalone distributions.
>>   
>> OK, then how do we proceed? Do you want a specific proposal or do you
>> want to propose something. You would have to be the one to modify the
>> scripts.
> If anyone has ideas, I'm open to them.
>
> Currently, we have www.coin-or.org/download with directories binary,
> rpm, source.  It doesn't look like the contents of the rpm directory are
> being maintained since about 2008, so I suppose we could blow it away
> and start from scratch.
>
> We could either have project subdirectories with source directories
> inside or a global source directory with project directories inside.  If
> we're going to think about providing RPMs for other distributions (RHEL
> 6, for example), then we could have global directories for the
> distributions with project directories inside or have distro
> subdirectories inside project directories.
>
> Without thinking hard about it yet (I've been hacking Trac registration
> all afternoon without quite getting it), I think I lean toward
> downloads/rpms/<project>/ with a source subdirectory and a directory for
> each distro with RPMs and SRPMs.
>
> Matt
>
>> Cheers,
>>
>> Ted
>> -- 
>>
>> Dr. Ted Ralphs
>> Associate Professor, Lehigh University
>> (610) 628-1280
>> ted 'at' lehigh 'dot' edu
>> coral.ie.lehigh.edu/~ted
>>