Chronological Thread 

< Chronological >      < Thread >

---

Andrew Miller wrote:
> Alan Garny wrote:
>> David Nickerson wrote:
>>
>>> Andrew Miller wrote:
>>>
>>>> David Nickerson wrote:
>>>>
>>>>> Thanks Andrew. So just to make sure I'm getting it right, in the trunk
>>>>> code CCGS is now a service sitting on top of CaVAS, MaLaES, etc.,
>>>>>
>> right?
>>
>>>> Thats right, so you need to enable those services in configure in order
>>>> to enable CCGS.
>>>>
>>> ok, thanks. if I just do a '--enable-ccgs' on my configure, does that
>>> enable the new services or do I need to explicitly enable each one?
>>>
>>> (my current configure command is something like:
>>> ../source/configure --prefix $HOME/std-libs/physiome/ --enable-corba=no
>>> --enable-context=no --enable-ccgs --enable-cis=no --enable-server=no
>>> --enable-static --enable-shared=no
>>> )
>>>
>> I wonder why we don't have something simpler, i.e. everything is disabled
>> by
>> default and if you want something enabled, then just mention it. In other
>> words to have Andre's configure command above, we would use:
>>
>> ../source/configure --prefix $HOME/std-libs/physiome/ --ccgs --static
>>
>> Note that I removed the "enable-" bit, as I really don't see the point for
>> it.
>>
> Hi Alan,
>
> Everything is disabled by default, so you need to turn things on
> explicitly, as you suggested.
>
> I agree that it might be nice to turn on dependencies automatically - we
> don't do that now, so you need to manually specify everything that
> should be built.

given that CCGS won't function without the required services (right?),
shouldn't the configure stop with an error if the required services are
not enabled? or simply have the required bits turn on automatically
unless they are specifically disabled...

> With regards to the --enable suffix, I think that it is better to stick
> with the autoconf defaults, since autoconf based programs are very
> common, and if we were to break the standard convention we would just
> confuse everyone (not to mention that one day we might have some feature
> that we might want to turn on by default, so we would need --disable- to
> override this).

yep - best to stick to the standard...could maybe provide documented
example configure commands to help people unfamiliar with the autoconf
based approach.

>>> Might be nice for the API documentation on the website to be updated to
>>> describe all this...although I guess its covered under the last item on
>>> the current milestone page (http://www.cellml.org/tools/api/Milestones).
>>>
>> I hope this is going to be done. I am working with Andrew on getting some
>> developer documentation for everything that is required to recompile PCEnv,
>> so that will include the CellML API.
>>
> We can probably get most of the way with respect to the documentation on
> the API structure just by running the interfaces through Doxygen.

The documentation I was talking about is not the API level
documentation, although that would also be nice to have. I was after
something a bit more high level. Essentially a documented version of the
core parts of CellML2C code would be a good start...


andre.

---

• [cellml-discussion] CeVAS, CUSES, MaLaES, David Nickerson, 08/19/2007
  • [cellml-discussion] CeVAS, CUSES, MaLaES, Andrew Miller, 08/20/2007
    • [cellml-discussion] CeVAS, CUSES, MaLaES, David Nickerson, 08/20/2007
      • [cellml-discussion] CeVAS, CUSES, MaLaES, Andrew Miller, 08/20/2007
        • [cellml-discussion] CeVAS, CUSES, MaLaES, David Nickerson, 08/20/2007
          • [cellml-discussion] CeVAS, CUSES, MaLaES, Alan Garny, 08/20/2007
            • [cellml-discussion] CeVAS, CUSES, MaLaES, Andrew Miller, 08/20/2007
              • [cellml-discussion] CeVAS, CUSES, MaLaES, David Nickerson, 08/20/2007

---

Archive powered by MHonArc 2.6.18.