From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,170b136bef612224 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 X-Received: by 10.180.75.7 with SMTP id y7mr7032648wiv.0.1367665840714; Sat, 04 May 2013 04:10:40 -0700 (PDT) Path: p18ni66813wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!backlog2.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!News.Dal.Ca!citadel.nobulus.com!goblin3!goblin.stu.neva.ru!news.tu-darmstadt.de!news.internetdienste.de!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail User-Agent: NewsTap/3.5.5 (iPad) From: Georg Bauhaus Newsgroups: comp.lang.ada Mime-Version: 1.0 Message-ID: <989258155388777873.634822rm-host.bauhaus-maps.arcor.de@news.arcor.de> Subject: Re: Specifying a target in a GPRBuild project file? References: <517bd35b$0$6643$9b4e6d93@newsspool2.arcor-online.net> Date: 27 Apr 2013 18:30:00 GMT Organization: Arcor NNTP-Posting-Date: 27 Apr 2013 20:30:00 CEST NNTP-Posting-Host: b7f0d45b.newsspool2.arcor-online.net X-Trace: DXC=S87M1Il7<]8d8Nb@@ZG@b=A9EHlD;3Yc24Fo<]lROoR18kFejV83<:oJ7cb9\2MlK Yannick Duchêne (Hibou57 ) wrote: >> Just imagine some portable combined Ada/C++ program source text that has >> become the subject of GPRbuild (alternatively, to whatever Atego's >> Rational thing does, etc). Will porting the Ada/C++ program still be >> both practical and cost efficient in the presence of having to port >> one proprietary (open-source) configuration text to another proprietary >> (maybe-not-open-source) configuration text? > > In this case, just use a classic Makefile and describe in a README file, > what may have to be tweaked in it (compiler paths, names, options, etc). Makefiles do not solve the recurring problem of configuring sets of tools: When a source text of a mixed Ada and C++ program is perfectly portable, why is it necessary to have elaborate but incompatible *tool* configuration texts? Suppose you have successfully tested the program with the front ends of GCC on some platform. You are now moving towards a combination of non-GNAT and non-G++ compilers and tools. As a consequence, you will be spending time and money on expressing the very same ideas once more, this time using different tool configuration languages. The only profit from having worked on a Makefile or GPR project file is to have thought about it. If someone knows non-GCC configuration well, but does not know GCC's configuration mini-languages, he or she will learn very little from either. Note that he or she does not need to learn the subject of configuring tools, they know that. But the lack of a common configuration language forces them to learn yet another vendor's language for expressing common ideas. Doesn't this sound familiar? Expressing formal things in many incompatible vendor languages? >> Who is financing this misguided use of brain power that creates >> monstrosities of configuration to live in a costly zoo? > > There is nothing monstrous with it, it just fix compilers paths and > options, and default project files attributes and variables. Try porting one so that it can be used from within a very different toolset for the same purpose.