autotools-idl-general — General discussion (user help, bugreports, requests for features, suggestions)

Re: [autotools-idl] IDL include paths

[Milo H. F. <mf...@pa...>]

Thx Vlado -- I got off on the wrong foot using IDLCXXFLAGS

v/r
milo

>-----Original Message-----
>From: Vladimir Panov [mailto:gb...@vo...]
>Sent: Tuesday, April 08, 2014 16:20
>To: Milo H. Fields
>Cc: aut...@li...
>Subject: Re: [autotools-idl] IDL include paths
>
>Hi, Milo.
>
>It is just like for C/C++, only the variable is named IDLCPPFLAGS instead of
>CPPFLAGS. I.e. here are the rules:
>
>1. Put your (the maintainer's) additions in AM_IDLCPPFLAGS. If you need it
>global then just do it in every Makefile.am with the same substituted value
>from configure.ac.
>2. Your user will put his global additions in IDLCPPGLAGS. A help message is
>available in "configure --help" about this.
>
>It is possible to add your global additions in IDLCPPFLAGS in configure.ac
>instead of in all Makefile.am's. In configure.ac use the
>following:
>IDLCPPFLAGS="${IDLCPPFLAGS} ..."
>Make sure to append but not to substitute or you will overwrite your user's
>additions.
>
>I personally prefer the rule:
>AM_IDLCPPFLAGS is for the maintainer.
>IDLCPPFLAGS is for the user.
>
>Vlado
>
>
>Milo H. Fields wrote:
>> Greetings, Vlado!
>> Could you tell me the 'recommended' method for extending the IDL
>> search path for the IDL complier - for both a configure.ac system wide
>> and local Makefile.am?
>>
>> v/r
>> Milo
>>
>>
>>
>> ----------------------------------------------------------------------
>> --------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration Continuously
>> Automate Build, Test & Deployment Start a new project now. Try Jenkins
>> in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees
>>
>>
>>
>> _______________________________________________
>> autotools-idl-general mailing list
>> aut...@li...
>> https://lists.sourceforge.net/lists/listinfo/autotools-idl-general
>>

Re: [autotools-idl] IDL include paths

[Vladimir P. <gb...@vo...>]

Hi, Milo.

It is just like for C/C++, only the variable is named IDLCPPFLAGS 
instead of CPPFLAGS. I.e. here are the rules:

1. Put your (the maintainer's) additions in AM_IDLCPPFLAGS. If you need 
it global then just do it in every Makefile.am with the same substituted 
value from configure.ac.
2. Your user will put his global additions in IDLCPPGLAGS. A help 
message is available in "configure --help" about this.

It is possible to add your global additions in IDLCPPFLAGS in 
configure.ac instead of in all Makefile.am's. In configure.ac use the 
following:
IDLCPPFLAGS="${IDLCPPFLAGS} ..."
Make sure to append but not to substitute or you will overwrite your 
user's additions.

I personally prefer the rule:
AM_IDLCPPFLAGS is for the maintainer.
IDLCPPFLAGS is for the user.

Vlado


Milo H. Fields wrote:
> Greetings, Vlado!
> Could you tell me the 'recommended' method for extending the IDL search path
> for the IDL complier - for both a configure.ac system wide and local
> Makefile.am?
>
> v/r
> Milo
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
>
> _______________________________________________
> autotools-idl-general mailing list
> aut...@li...
> https://lists.sourceforge.net/lists/listinfo/autotools-idl-general
>

[autotools-idl] IDL include paths

[Milo H. F. <mf...@pa...>]

Greetings, Vlado!
Could you tell me the 'recommended' method for extending the IDL search path
for the IDL complier - for both a configure.ac system wide and local
Makefile.am?

v/r
Milo

Re: [autotools-idl] tao_idl update

[Milo H. F. <mf...@pa...>]

Vlado,
That did the trick!  I'm finding this to be an extremely useful package
thanks!

v/r
milo 

-----Original Message-----
From: Vladimir Panov [mailto:gb...@vo...] 
Sent: Wednesday, April 02, 2014 13:08
To: Milo H. Fields
Cc: aut...@li...
Subject: Re: [autotools-idl] tao_idl update

Hi, Milo.

I have just released autoconf-orb 1.2.5 with a fix for the removed tao_idl's
option. You may also check automake 1.2.1-1.14.1 - there are no fixes or new
features there but you may find the latest version of automake handy.
If you have other problems, please let me know here.

Vlado

Milo H. Fields wrote:
> Greetings,
>
> It appears that current implementation for the tao_idl compiler has 
> not been updated to the current version (2.2a_p1).  Is the project 
> still being maintained?  Could you point me in the general direction 
> of where the unique IDLCXXFLAGS are generated so that I might be able 
> to modify the rpm build?  I'm able to coerce the generated build 
> environment however I was looking to update the system to recognize 
> the updated compiler.
>
> v/r
>
> milo
>
>
>
> ----------------------------------------------------------------------
> --------
>
>
>
> _______________________________________________
> autotools-idl-general mailing list
> aut...@li...
> https://lists.sourceforge.net/lists/listinfo/autotools-idl-general
>

Re: [autotools-idl] tao_idl update

[Vladimir P. <gb...@vo...>]

Hi, Milo.

I have just released autoconf-orb 1.2.5 with a fix for the removed 
tao_idl's option. You may also check automake 1.2.1-1.14.1 - there are 
no fixes or new features there but you may find the latest version of 
automake handy.
If you have other problems, please let me know here.

Vlado

Milo H. Fields wrote:
> Greetings,
>
> It appears that current implementation for the tao_idl compiler has not
> been updated to the current version (2.2a_p1).  Is the project still
> being maintained?  Could you point me in the general direction of where
> the unique IDLCXXFLAGS are generated so that I might be able to modify
> the rpm build?  I’m able to coerce the generated build environment
> however I was looking to update the system to recognize the updated
> compiler.
>
> v/r
>
> milo
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> autotools-idl-general mailing list
> aut...@li...
> https://lists.sourceforge.net/lists/listinfo/autotools-idl-general
>

[autotools-idl] tao_idl update

[Milo H. F. <mf...@pa...>]

Greetings,

It appears that current implementation for the tao_idl compiler has not been
updated to the current version (2.2a_p1).  Is the project still being
maintained?  Could you point me in the general direction of where the unique
IDLCXXFLAGS are generated so that I might be able to modify the rpm build?
I'm able to coerce the generated build environment however I was looking to
update the system to recognize the updated compiler.

 

v/r

milo

 

Re: [autotools-idl] IDLC undefined

[<na...@gm...>]

Vlado,

Your insight was correct; I managed to install autoconf-orb and its
macros went to /usr/share/aclocal, just as you said. I then installed
automake-idl with --prefix /usr/local.

Subsequent invocations of autoreconf produced the error message that I
reported in my first email. The problem did not resolve itself until I
re-installed autoconf-orb, just as you predicted. Now, I've got your
autotools examples configuring and making beautifully.

I didn't know that I could have avoided this by installing
automake-idl before autoconf-orb. How exactly does this order work to
fix the problem? In any case, thanks in advance for adding this
particular point to the documentation for future reference.

Also, thank you very, /very/ much for this extremely useful tool. If
autoconf-orb and automake-idl work well for my projects, you will have
literally saved me months of m4 hacking my own inferior solution.

Thanks again!

On Fri 2011 Dec 30 19:49, Vladimir Panov wrote:
> Hi, N.
> 
> The problem is that the autoconf-orb's macros are not installed
> where automake-idl expects them to be. The correct location can be
> obtained with this command:
> 
> aclocal --print-ac-dir
> 
> Please, check whether ai_orb.m4, et al. are there. If not then
> reinstall autoconf-orb using method 2. from the documentation:
> http://autotools-idl.sourceforge.net/autoconf-orb.html#installation
> 
> Here is my hypothesis on what has happened:
> You have had automake installed in /usr (from your distro, without
> IDL support). Then you have installed autoconf-orb. Its macros went
> to /usr/share/aclocal. Then you have installed automake-idl in
> /usr/local. Now your default automake has IDL support but it expects
> autoconf-orb's scripts in /usr/local/share/aclocal and they are not
> there.
> 
> Installing automake-idl before autoconf-orb would have avoided this
> problem. I will now improve the documentation to state this order
> explicitly.
> 
> Please, tell me if this does not help you. And thanks for your
> interest in autotools-idl :-)
> 
> Vlado
> 
> P.S. Usually, packages from your distro will install their autoconf
> scripts in /usr/share/aclocal even if you use non-distro automake
> installed in /usr/local. So it is a good idea to combine
> /usr/share/aclocal and /usr/local/share/aclocal into one directory
> (one to be a link to the other).
> 
> 
> N wrote:
> >Vladimir,
> >
> >I've installed autoconf-orb and automake-idl, but I'm getting an error
> >message when I try to autogenerate your examples:
> >
> >
> >nroza@lilith:/tmp/autotools-idl-examples-1.2.1$ ./autogen.sh
> >Makefile.am: IDL source seen but `IDLC' is undefined
> >autoreconf: automake failed with exit status: 1
> >ln: creating symbolic link `./idlfix': File exists
> >ln: creating symbolic link `./config.sub': File exists
> >ln: creating symbolic link `./config.guess': File exists
> >ln: creating symbolic link `./install-sh': File exists
> >ln: creating symbolic link `./idlfix': File exists
> >ln: creating symbolic link `./config.sub': File exists
> >ln: creating symbolic link `./config.guess': File exists
> >ln: creating symbolic link `./install-sh': File exists
> >
> >
> >Any idea what's happening?
> >
> >

--

Neil

[autotools-idl] IDLC undefined

[N <na...@gm...>]

Vladimir,

I've installed autoconf-orb and automake-idl, but I'm getting an error
message when I try to autogenerate your examples:


nroza@lilith:/tmp/autotools-idl-examples-1.2.1$ ./autogen.sh 
Makefile.am: IDL source seen but `IDLC' is undefined
autoreconf: automake failed with exit status: 1
ln: creating symbolic link `./idlfix': File exists
ln: creating symbolic link `./config.sub': File exists
ln: creating symbolic link `./config.guess': File exists
ln: creating symbolic link `./install-sh': File exists
ln: creating symbolic link `./idlfix': File exists
ln: creating symbolic link `./config.sub': File exists
ln: creating symbolic link `./config.guess': File exists
ln: creating symbolic link `./install-sh': File exists


Any idea what's happening?


-- 

Neil

Re: [autotools-idl] autotools-idl: Feature extension

[Vladimir P. <gb...@vo...>]

Hi, Olaf.

The feature to customize the names of the generated source files was 
released as autotools-idl 1.2.
There is a short description here:
http://autotools-idl.sourceforge.net/automake-idl.html#features
and the relevant examples are 8 and 9.

Vlado

Re: [autotools-idl] autotools-idl: Feature extension

[Olaf M. <ol...@ma...>]

Hello,

concerning this patch: there is no escaping in double-quoted strings
like "$(foo)" in automake.in. In the patch-file, change the following from:

+    $clean_files{$base . "$(IDL_STUB_CLNT).$(IDL_EXT_H)"} = MOSTLY_CLEAN;
+    $clean_files{$base . "$(IDL_STUB_SRV).$(IDL_EXT_H)"} = MOSTLY_CLEAN;
+    $clean_files{$base . "$(IDL_STUB_CLNT).$(IDL_EXT_C)"} = MOSTLY_CLEAN;
+    $clean_files{$base . "$(IDL_STUB_SRV).$(IDL_EXT_C)"} = MOSTLY_CLEAN;

to:

+    $clean_files{$base . "\$\(IDL_STUB_CLNT\).\$\(IDL_EXT_H\)"} =
MOSTLY_CLEAN;
+    $clean_files{$base . "\$\(IDL_STUB_SRV\).\$\(IDL_EXT_H\)"} =
MOSTLY_CLEAN;
+    $clean_files{$base . "\$\(IDL_STUB_CLNT\).\$\(IDL_EXT_C\)"} =
MOSTLY_CLEAN;
+    $clean_files{$base . "\$\(IDL_STUB_SRV\).\$\(IDL_EXT_C\)"} =
MOSTLY_CLEAN;

And from:

+        push (@generated_idl_headers, $base .
"$(IDL_STUB_CLNT).$(IDL_EXT_H)");
+        push (@generated_idl_headers, $base .
"$(IDL_STUB_SRV).$(IDL_EXT_H)");

to:

+        push (@generated_idl_headers, $base .
"\$\(IDL_STUB_CLNT\).\$\(IDL_EXT_H\)");
+        push (@generated_idl_headers, $base .
"\$\(IDL_STUB_SRV\).\$\(IDL_EXT_H\)");

No news on Debian integration, yet.

Olaf
-- 
Olaf Mandel   <ol...@ma...>   <http://www.olaf.mandel.name/>
PGP key:      1024D/33398848 2002-09-19
Fingerprint:  0E33 BEA6 1A71 9C5E 62BD  FC0E 99A7 D2C6 3339 8848

Re: [autotools-idl] autotools-idl: Feature extension

[Olaf M. <ol...@ma...>]

Vladimir Panov schrieb:
-Snipp-
> In the mean time, you may send me an example which uses your
> implementation, if you wish. I do not demand it but it would certainly
> be welcome. Ideally, it should be something like example5 from the
> documentation.

Hello,

I forgot about that. How about the attached patch file to base an
example off of example5? Please note that after applying the patch file,
you need to rename Simple_i.hpp to Simple_i.h.

Best regards,
Olaf
-- 
Olaf Mandel              eMail Ol...@Ma...

Re: [autotools-idl] autotools-idl: licensing question

[Olaf M. <ol...@ma...>]

Vladimir Panov schrieb:
> Olaf Mandel wrote:
-Snipp-
>> * In autoconf-orb, none of the *.m4 files contain a license notice.
>> [...]
>> At the moment, as per the COPYING file, all these files are covered by
>> the GPL3, so an appropriate header would probably look like this:
-Snipp-
> I decided not to put a copyright notice in every source file because I
> read somewhere (I don't remember where) that a COPYING file is enough
> for the whole package. Anyway, I will put the notice for the next
> release, if this is required by Debian.

Hi Vladimir,

I am not sure if it is "required" by Debian. But I am not a
DebianDeveloper myself and have to rely on the goodwill of the real DDs
to upload the package for me. One reply I got raised the issue of these
files becoming part of the distributed files of other packages, so he
wanted the copyright directly included to make the issue more obvious to
users of autoconf-orb.

If you don't mind, I will add the GPL3 header (the longer one I gave as
an example in the previous mail) to the package so I don't have to wait
for the next release.

>> * The license for autoconf-orb is GPLv3+ (with the autoconf exception).
>> This differs from the GPLv2+ that is used for autoconf and automake-idl.
>> Is this intentional?
-Snipp.
> If you feel that I 'm wrong here, please let me know why. I can easily
> revert back to GPLv2.
> 
I do not mind (I am a bit of a fan of the new GPLv3, myself). I just
wanted to rule out that the license was automatically applied by
"automake --add-missing" or the like, as has been guessed/feared by a DD.

-Snipp-
> 2. If you know any reason for autoconf-orb to be switched back to GPLv2
> then let me know.
I can't think of any reason.

> 3. Anything else?
Not at the moment. I will keep you apprised of any development on the
Debian-Inclusion front.

Best regards,
Olaf
-- 
Olaf Mandel              eMail Ol...@Ma...

Re: [autotools-idl] autotools-idl: licensing question

[Vladimir P. <gb...@vo...>]

Olaf Mandel wrote:
> Hello,
>   
Hi, Olaf.

IANAL, too, so feel free to object to everything I've written below.
> I am currently trying to package autotools-idl for Debian (my first
> package, please be kind), and in doing so was pointed to a few questions
> concerning licensing of your code:
>
> * In autoconf-orb, none of the *.m4 files contain a license notice. I
> saw that files from the official autoconf package contain a copyright
> notices that are quite a bit less restrictive than the GPL that governs
> your package. Directly applied to your code this would read:
>
> dnl Copyright (C) 2004-2008 Vladimir Panov.
> dnl This file is free software; the author
> dnl gives unlimited permission to copy and/or distribute it,
> dnl with or without modifications, as long as this notice is preserved.
>   
No, this doesn't look like the GPL.
> At the moment, as per the COPYING file, all these files are covered by
> the GPL3, so an appropriate header would probably look like this:
>
> dnl Copyright (C) 2004-2008 Vladimir Panov.
> dnl This file is free software: you can redistribute it and/or modify
> dnl it under the terms of the GNU General Public License as published by
> dnl the Free Software Foundation, either version 3 of the License, or
> dnl (at your option) any later version.
> dnl This file is distributed in the hope that it will be useful,
> dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
> dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> dnl GNU General Public License for more details.
> dnl You should have received a copy of the GNU General Public License
> dnl along with this file.  If not, see <http://www.gnu.org/licenses/>.
> dnl As a special exception to the GNU General Public License, if you
> dnl distribute any part of this file as part of a program that contains a
> dnl configuration script generated by Autoconf, you may include it under
> dnl the same distribution terms that you use for the rest of that program.
>   
This one is OK.
> Please tell me which header I am supposed to put in (or put such a
> header into your own sources).
>   
I decided not to put a copyright notice in every source file because I 
read somewhere (I don't remember where) that a COPYING file is enough 
for the whole package. Anyway, I will put the notice for the next 
release, if this is required by Debian.
> * The license for autoconf-orb is GPLv3+ (with the autoconf exception).
> This differs from the GPLv2+ that is used for autoconf and automake-idl.
> Is this intentional?
>   
Both yes and no:
Yes, I intentionally switched to GPLv3 (out of pure zealotry :-).
No, autoconf-orb's license doesn't have to be the same as autoconf's. 
autoconf-orb is not derived from autoconf. The relation between the two 
is like a C program file and a header from glibc. I could have chosen 
any license for autoconf-orb.
If you feel that I 'm wrong here, please let me know why. I can easily 
revert back to GPLv2.

> * In automake-idl, the copyright to _all_ files, the patched ones and
> the ones that only exist in automake-idl lies with the Free Software
> Foundation (FSF). Is this intentional (maybe in preparation for later
> upstream inclusion)?
>   
Since the main part of automake-idl is a patch for automake.in (I can't 
change the license here), and the latter already has a copyright notice, 
I decided not to copyright the rest of the files differently.
About the upstream inclusion - not that I don't want it, but I doubt 
that it would ever be accepted (autoconf-orb has become quite a beast, 
and automake-idl doesn't make sense without it; besides, CORBA is not 
very popular these days), so I've decided not to try it.
> * Were you the only author, so that you were able to give up the
> copyright on the automake-idl changes to the FSF and are able to make
> decisions on licensing?
Yes, I am the only author.
> Concerning that: if you want to use my previous
> patch I sent, I waive copyright on it, and put it in the Public Domain.
>   
Thanks :-)
> That is, if I can even hold copyright on such a minimal change... :-)
> But IANAL (I Am Not A Lawyer), so I thought I better write this.
>
> If you could clarify these points, please.
>   
In short:
1. I will put the copyright notices in autoconf-orb's files in the next 
release.
2. If you know any reason for autoconf-orb to be switched back to GPLv2 
then let me know.
3. Anything else?
> Thanks,
> Olaf
>   
Vlado

Re: [autotools-idl] autotools-idl: Feature extension

[Vladimir P. <gb...@vo...>]

Olaf Mandel wrote:
> Hello,
>
> I wrote a small feature extension for your autotools-idl package, that I
> think might be of general interest:
>
> At the moment, the Makefile creates from each foo.idl file four files:
>
> foo.cpp
> foo.hpp
> fooServer.cpp
> fooServer.hpp
>
> But these names might not generally be desirable. Either the user just
> has different tastes, or an existing project gets converted to
> autotools-idl, there might be different reasons.
>
> I added four Makefile variables to customize the names. Now the files are:
>
> foo$(IDL_STUB_CLNT).$(IDL:EXT_C)
> foo$(IDL_STUB_CLNT).$(IDL:EXT_H)
> foo$(IDL_STUB_SRV).$(IDL:EXT_C)
> foo$(IDL_STUB_SRV).$(IDL:EXT_H)
>
> The variables have defaults to replicate the previous behavior (see
> idl.am). Also, the new automake-idl works together with configure files
> created with an old autoconf-orb. Just the new autoconf-orb needs a new
> automake-idl to work (the IDLCXXFLAGS is invalid, otherwise).
>
> ATTENTION: This has only tested with the omniorb IDLC. The other IDLCs
> are completely untested.
>
> Additionally, the automake-idl patch contains one extra line in
> idlfix.m4: for omniorb, the fooServer.cpp file included foo.hpp, where
> it should have included fooServer.hpp. This has been changed.
>
> Please let me know what you think and if you will be including the
> patches. Thanks.
>
> Best regards,
> Olaf Mandel
>   
Hi, Olaf.

Thank you for your interest in autotools-idl :-) Your feedback is the 
first one I get since I started the project almost 4 years ago.

About your feature request - I had this idea in the very beginning but I 
dismissed it as a "nobody would need it" feature. You prove me to be 
wrong so I will definitely try to implement it.
However, I can't promise you that I will base the implementation on your 
patch - I will review it for sure. I can't give you a time estimation as 
well but it will most probably be in the next couple of months. Also, 
have in mind that backward compatibility is my top priority, so the end 
result might not be of maximum convenience.
In the mean time, you may send me an example which uses your 
implementation, if you wish. I do not demand it but it would certainly 
be welcome. Ideally, it should be something like example5 from the 
documentation.

Vlado