[RFC] Refactor autoconf options and build scripts

[Jasmin J.]

Bryan,

>>> ct-ng <sample>
>>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2
>> I don't know how much lines this will be at the end. It is always a trade
>> off ... .
> 
> one line of:
> 
> export CT_blah_blah
> 
> in kconfig.mk for each option.
I meant the resulting log output to the console. If it is too much it is not
readable and we might better "cat build.log" at the end.

> Rather then confusing users with different samples using different
> versions, why not just create a separate git repository with the
> samples, then clone the test samples before running the test. Just a
> thought.
You are the CT-NG maintainer, so you have to define how the repo is structured.
I personally like the idea to separate samples from tests. But I wouldn't use
another repo, but a new sub directory "testing". There we can add what ever we
need, test scripts, test configurations, ... .

> I think the only downside to travis-ci is that while the build may be
> successful, the toolchain itself can still be totally useless.
This is totally true, but it will detect simple mistakes, like mine with
isl/ClooG/gcc-5.x dependencies. So I could have seen this much earlier.
I guess most of the changes in CT-NG are currently related to new package
versions and new configuration options, like my LIBC_NEWLIB_TARGET_CFLAGS.

> When I researched travis-ci previously, it wasn't able to do this (it
> would take longer then there storage limitations and timeout
> restrictions.
I haven't found a configuration to extend the 50 minutes on travis-ci. There
is the possibility to extend the 10 minutes limit (printing to stdout/stderr).
The command needs to be prefixed with "travis_wait". This will print every
minute a short log.

> So I started looking at getting a server and setting up jenkins-ci, so
> that I can be in control of the test environment, and a much larger
> storage restriction and no timeouts for tests. (I mean obviously we
> would want to say that the test is dead if it took longer then X
> minutes/hours.)
Would you like to see travis-ci integrated with CT-NG?
When you will get your server for jenkins-ci?

If the answer to the second question is "within a short time" (e.g. a handful
weeks), then it makes no sense to put effort into travis-ci. jenkins-ci can be
integrated to GitHub, too:
  https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin
I guess it would be possible to run automated test for every pull request like
travis-ci offers.
Moreover, you could allow all users who have a CT-NG fork to start/stop tests
on their forks, too (manually only). Thus, you could define a pull request have
to have a positive test result on your Jenkis server. Then the test effort is
spread over time due to the different locations of the contributors and you
need much less time to accept pull requests.

Independent of the used tool, we need the test-setup mentioned above (subdir
testing) with preconfigured package combinations, which are known to work.

BR
   Jasmin

PS: I asked my partner, who is an ISP, for server space. Currently there aren't
    any resources free, but this might change with the new 48 Core/128GB RAM
    machine, which is planned for Feb. 2016.

--
For unsubscribe information see http://sourceware.org/lists.html#faq