Re: imake
On Mon, Sep 29, 2014 at 5:58 AM, Joshua Root wrote: rasmol - Packaged version released in 2008, latest release was in 2009 This is probably used by some of our scientist users. There does seem to be a 2.7.5.2 release from 2011, and more files added to their sourceforge site in 2013. So certainly not dead. (Probably just developed by academics in their spare time, like many such tools.) I totally agree with the last few sentences. I used rasmol lot in the past, but haven't used it for years now. Tools like pymol have been developed in the meantime which are using newer technologies and are slightly more user-friendly. Still, this doesn't mean that authors shouldn't be asked about moving to a modern build system. Or that MacPorts definitely needs to support the tool (they seem to provide some apple-specific downloads). Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Releasing code as portgroup instead of in base/ (was Re: imake)
On Sep 28, 2014, at 2:55 AM, Ryan Schmidt ryandes...@macports.org wrote: Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. I think we really should move in the other direction: -make releases easier -less code in portgroups (move as much as possible to base/) someone can say I did foo with macports version x.y.z, it's hard for an end-user to know I did foo with macports verison x.y.z and the revision of portgroup blah that I got in my last portsync which corresponds with rXX in your repo -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 29/09/2014, at 3:25 PM, Nicolas Pavillon wrote: On 29/09/2014 13:03, Brandon Allbery wrote: On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. I had mentioned the idea of making KDE3 obsolete quite some time ago (months) on the list, but never got to do it. I indeed started (independently from the imake discussion, just a coincidence) some days ago with the dependents ports. I going slightly slowly on this part as I am trying to find replacements for the few remaining kde3-based apps whenever possible. The idea would be to then remove the kde3 suite after all dependents have been taken care of. The biggest remaining issue is koffice. Ideally, it could be replaced by calligra (requested in ticket #https://trac.macports.org/ticket/37579), but it seems plagued with several problems at runtime making it only very partly usable on OS X. As Ryan said, it is not really the duty of MacPorts developers to keep ports alive if they are not supported upstream. KDE 3 is long since dead (unmaintained) and all KDE apps dependent on KDE 3 with it. So, do not worry about KOffice… :-( As a KDE developer, I do not like this aspect of KDE, but it is a fact of life. If there is nobody available to port a KDE app to a new version of KDE, then the app becomes unmaintained and is no longer released. KDE 4 is heading that way right now, as the emphasis (in the KDE project) shifts to Frameworks and KF5. Marko, René and I are working to make the transition easier for MacPorts developers and users this time around. When we have time, we should see what can be done to make Calligra more workable in KDE 4 on Apple OS X. ATM I do not see more than a trickle of KDE 4 apps that have been ported to KF5. Maybe that will become a flood later. Meanwhile, I do not know what other FOSS office suites might be a goer on MacPorts. I use LibreOffice… Cheers, Ian W. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If we come up with a better solution later that doesn't involve needing the big gcc dependency, great, we can improve it then. I'm just tired of this problem and want to make *something* that works, rather than what we currently have where all imake-using ports are broken with Xcode 5 or later. Some of those are dependencies of software I maintain so I'm eager to resolve this. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 16:55 , Ryan Schmidt wrote: On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. So you could at least use llvm-gcc42 on 10.8 and 10.9 then, and gcc49 on 10.10+. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If I were going there, I wouldn't start here. If you want the programs to build right, put your effort into moving them off of imake. Most of them aren't very big. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Hi, - On 28 Sep, 2014, at 04:15, Ryan Schmidt ryandes...@macports.org wrote: My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. You could try using /usr/bin/clang -E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -x assembler-with-cpp as preprocessor. That's what GHC uses to preprocess its non-C macros, and it works there. I wouldn't be surprised if it didn't work for you, but I guess it's worth a shot. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 5:22 AM, Clemens Lang c...@macports.org wrote: as preprocessor. That's what GHC uses to preprocess its non-C macros, and it works there. Mostly works. There are still cases where you can't turn off the implicit dependency on C tokens, as I outlined previously. GHC 7.10 is moving away from relying on a C compiler to provide a usable preprocessor entirely because of this. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 2:41 AM, Joshua Root wrote: On 2014-9-28 16:55 , Ryan Schmidt wrote: On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. So you could at least use llvm-gcc42 on 10.8 and 10.9 then, and gcc49 on 10.10+. You mean using the macports llvm-gcc42 port instead of the gcc49 port? Sure, we could that. It is a much smaller package. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If I were going there, I wouldn't start here. If you want the programs to build right, put your effort into moving them off of imake. Most of them aren't very big. I'm not sure I know how to do that. I have no experience with these packages' build systems or with imake, and although I can write a basic Makefile, I haven't ever written anything using autotools or cmake or similar. If the developers of those programs want to switch to those systems, that would be great, but I don't consider it my job to rewrite their configuration system for them. But I'm hopeful that I'm able to accomplish writing a xmkmf portgroup that would work. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: spim ivtools magicpoint tgif xfig kdebase3 transfig arb rasmol openvas-server canna emiclock fvwm kinput2 kxterm sunclock tightvnc vtwm wmclock xcb xearth xmove xsnow xspringies xtu --Jeremy On Sep 27, 2014, at 19:15, Ryan Schmidt ryandes...@macports.org wrote: I'm going to try to work on the imake problem, specifically that ports using imake fail with Xcode 5 and up because they require a cpp with traditional cpp support which clang doesn't have. In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. Let me know if you have any objections to this proposal or if you have other ideas how to solve this problem. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 7:42 PM, Jeremy Huddleston Sequoia wrote: Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: spim ivtools magicpoint tgif xfig kdebase3 transfig arb rasmol openvas-server canna emiclock fvwm kinput2 kxterm sunclock tightvnc vtwm wmclock xcb xearth xmove xsnow xspringies xtu I don't plan to remove these ports. I cannot speak for all of them, but as I said earlier, some of the ports I maintain depend on some of the above ports. In particular, pure-octave depends on octave which depends on transfig. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 17:44, Ryan Schmidt ryandes...@macports.org wrote: On Sep 28, 2014, at 7:42 PM, Jeremy Huddleston Sequoia wrote: Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: I don't plan to remove these ports. I cannot speak for all of them, but as I said earlier, some of the ports I maintain depend on some of the above ports. In particular, pure-octave depends on octave which depends on transfig. Then let's fix transfig (or just remove the imake-dependent portions of it). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: sunclock - No upstream any more Possibly the site is just down at the moment; I remember looking at it not that long ago. FreeBSD updated to a new upstream release in 2013. They are not using imake to build it, but a Makefile.noimake which is provided in the release. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: xcb - No upstream(?), upstream 505s, port last updated in 2009 The homepage listed in the port redirected to http://oldhome.schmorp.de/marc/xcb.html for a while. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 11:21 PM, Jeremy Huddleston Sequoia jerem...@apple.com wrote: If I hear no objections in the next few days, I'll remove the ports in that first group. If nobody speaks up, I think we should nuke KDE3 in a few weeks. If I understood other discussions correctly, KDE3 is already being removed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: tgif - Upstream no longer exists, shipped version was released in 2001 Just need to remove the port number from the homepage URL. http://bourbon.usc.edu/tgif/ Latest release was 2011: http://bourbon.usc.edu/tgif/relnotes/ rasmol - Packaged version released in 2008, latest release was in 2009 This is probably used by some of our scientist users. There does seem to be a 2.7.5.2 release from 2011, and more files added to their sourceforge site in 2013. So certainly not dead. (Probably just developed by academics in their spare time, like many such tools.) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 20:58, Joshua Root j...@macports.org wrote: On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: tgif - Upstream no longer exists, shipped version was released in 2001 Just need to remove the port number from the homepage URL. http://bourbon.usc.edu/tgif/ Latest release was 2011: http://bourbon.usc.edu/tgif/relnotes/ Here's a possible patch to latest. tgif.patch Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Hello, On 29/09/2014 13:03, Brandon Allbery wrote: On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com mailto:allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. I had mentioned the idea of making KDE3 obsolete quite some time ago (months) on the list, but never got to do it. I indeed started (independently from the imake discussion, just a coincidence) some days ago with the dependents ports. I going slightly slowly on this part as I am trying to find replacements for the few remaining kde3-based apps whenever possible. The idea would be to then remove the kde3 suite after all dependents have been taken care of. The biggest remaining issue is koffice. Ideally, it could be replaced by calligra (requested in ticket #https://trac.macports.org/ticket/37579), but it seems plagued with several problems at runtime making it only very partly usable on OS X. Cheers, Nicolas ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 12:15 , Ryan Schmidt wrote: I'm going to try to work on the imake problem, specifically that ports using imake fail with Xcode 5 and up because they require a cpp with traditional cpp support which clang doesn't have. In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. Let me know if you have any objections to this proposal or if you have other ideas how to solve this problem. It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org wrote: It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. This probably isn't possible; the issue is that a modern preprocessor speaks C / C++, not Makefile. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 13:14 , Brandon Allbery wrote: On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org mailto:j...@macports.org wrote: It would be better to fix the macros in xorg-cf-files or wherever so they work with a modern preprocessor. This probably isn't possible; the issue is that a modern preprocessor speaks C / C++, not Makefile. That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: /opt/local/lib/X11/config/Imake.tmpl:2144:10: fatal error: ' X11 .rules' file not found #include ProjectRulesFile ^ /opt/local/lib/X11/config/Imake.tmpl:2142:35: note: expanded from macro 'ProjectRulesFile' # define ProjectRulesFile Concat3(,TopLevelProject,.rules) ^ /opt/local/lib/X11/config/Imake.rules:256:23: note: expanded from macro 'Concat3' #define Concat3(a,b,c)a/**/b/**/c ^ 1 error generated. It wants this to expand as: #include X11.rules but instead it expands as #include X11 .rules The gcc manual says you can use ## for pasting, but the result has to be a valid token. Hence: error: pasting and TopLevelProject does not give a valid preprocessing token - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org wrote: That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: That is in fact closely related to the issue. The old KR preprocessor allowed that as a hack; ANSI C required that comments expand to spaces, and provided new # and ## operations for token splicing --- but these require valid C tokens. # define ProjectRulesFile Concat3(,TopLevelProject,.rules) may happen to work if you update it to use ANSI token splicing --- but I doubt it, since it's designed for valid C tokens and you're trying to generate a single invalid C token. Also watch what happens with single quoted strings when xmkmf expands macros in Imakefiles. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 13:55 , Brandon Allbery wrote: On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org mailto:j...@macports.org wrote: That isn't the issue AFAICT, it's just doing things with comments that were probably undefined before and now don't work: That is in fact closely related to the issue. The old KR preprocessor allowed that as a hack; ANSI C required that comments expand to spaces, and provided new # and ## operations for token splicing --- but these require valid C tokens. # define ProjectRulesFile Concat3(,TopLevelProject,.rules) may happen to work if you update it to use ANSI token splicing --- but I doubt it, since it's designed for valid C tokens and you're trying to generate a single invalid C token. It does, with a little tweaking. But you're still right, it then proceeds to screw up the indentation in the Makefile. Also watch what happens with single quoted strings when xmkmf expands macros in Imakefiles. Yeah, that's already been patched. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 12:28 AM, Joshua Root j...@macports.org wrote: It does, with a little tweaking. But you're still right, it then proceeds to screw up the indentation in the Makefile. Yeh. I got to know this stuff all to well trying to deal with Haskell's use of CPP --- Haskell tokens just aren't compatible with C tokens, and there simply is no way to reconcile them in a way that wil alow clang's CPP to work properly in all cases. Some of those same screw cases come up here as well, but at least you're spared the really nasty ones like the way single quotes are sometimes Char literals, sometimes word characters, and then there's Template Haskell's use of prefix '' for Lisp-style quoting of types. My conclusion then was the same as now: ANSI CPP wants to be used on C, and is completely unsuited for anything else. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
