AdaWorks/APQ :: Build System :: Call for Help!

This is a discussion on AdaWorks/APQ :: Build System :: Call for Help! within the ADA forums in Programming Languages category; Hello there, AdaWorks is a big and ambitious project. I'm about to make our first release and we will already ship 9 modules + 8 sample modules. In such a complex system, the build system is always a concern. During AdaWorks development we decided to use GPR and include dependencies using a completely relative path so we could easily work with branches and the trunk at the same time by means of changing only one environment variable (ADA_PROJECT_PATH). But one thing we haven't considered is when the users will download our work and try it. This ticket has been opened ...

Go Back   Application Development Forum > Programming Languages > ADA

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 08-09-2008, 05:40 PM
OgRo
Guest
 
Default AdaWorks/APQ :: Build System :: Call for Help!

Hello there,

AdaWorks is a big and ambitious project. I'm about to make our
first release and we will already ship 9 modules + 8 sample modules.

In such a complex system, the build system is always a concern.
During AdaWorks development we decided to use GPR and include
dependencies using a completely relative path so we could easily work
with branches and the trunk at the same time by means of changing only
one environment variable (ADA_PROJECT_PATH).

But one thing we haven't considered is when the users will
download our work and try it.

This ticket has been opened so we could discuss this:
http://www.adaworks.net/adaworks/ticket/65

Please, any help on this issue will be appreciated.

PS: for those who don't know yet. Warren has given me and my team
maintainer rights over APQ and now it's part of AdaWorks and have
(with Warren's bless) changed from a dual license model to GMGPL
license. We intended to include ODBC and M$ SQL Server support in it,
but we haven't managed to finish those modules yet - even though they
exist in the svn trunk and they are somewhat working.

PS2: yes, I am yet to write the release notes and make a proper
release but you can download the files (if you don't have subversion
installed) from http://www.adaworks.net/releases.
Reply With Quote
  #2  
Old 08-10-2008, 01:30 PM
Peter C. Chapin
Guest
 
Default Re: AdaWorks/APQ :: Build System :: Call for Help!

OgRo wrote:

> In such a complex system, the build system is always a concern.
> During AdaWorks development we decided to use GPR and include
> dependencies using a completely relative path so we could easily work
> with branches and the trunk at the same time by means of changing only
> one environment variable (ADA_PROJECT_PATH).


In the discussion on the Trac ticket you say

"You need all project folders in the ADA_PROJECT_PATH environment
variable so it will build."

I'm wondering what you mean specifically by "all project folders." I
see 30 folders in the root, but I'm guessing you don't mean all of those.

Peter
Reply With Quote
  #3  
Old 08-10-2008, 04:26 PM
OgRo
Guest
 
Default Re: AdaWorks/APQ :: Build System :: Call for Help!

On 10 ago, 14:30, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> I'm wondering what you mean specifically by "all project folders." I
> see 30 folders in the root, but I'm guessing you don't mean all of those.
>
> Peter


No. "Only" the ones you need - and their dependencies.

So far someone would have 9 modules (and it also depends in which
database environments the user will require). We won't have more than
12 to 15 modules and, still, this organization was proposed only for
the indoor development environment. Now I'm bring this issue open so
people can share their thoughts and we can come to a conclusion in the
clearest way possible.

Notice our main development environment is Linux and it's _really_
straightforward to build such environment variable using bash. For Ms
Windows I believe it's not quite the same. Also, I am aware of the
length limitation of environment variables and putting every project's
path into ADA_PROJECT_PATH is not practical (imagine 100 projects with
different paths... crazy!).

But there are still two things we got to make possible: mixing
branches with the trunk modules and providing an efficient way for
users to compile our base code.
Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 01:58 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.